chore(workflow): complete step 6 (plan v1.2.0), start step 7

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/technical/decisions.md

@@ -78,3 +78,48 @@
 - Retrocompatible : les nouveaux parametres ont des valeurs par defaut None
 - Sous-chaine est intuitive pour l'utilisateur (pas besoin de connaitre les regex)
 - Le filtrage est post-fetch car l'API Gitea ne supporte pas le filtre par nom
+
+## ADR-006 : Ajout du module exporter.py (v1.2.0)
+
+**Date** : 2026-03-12
+**Statut** : accepte
+
+**Contexte** : L'export JSON est une nouvelle responsabilite. L'ajouter a `display.py` melangerait serialisation structuree et formatage Rich. ADR-002 limitait a 4 modules pour v1.0.0.
+
+**Decision** : Creer `exporter.py` pour la serialisation des donnees (JSON, et futurs formats). Le projet passe a 5 modules.
+
+**Consequences** :
+- Separation claire : `display.py` = rendu terminal, `exporter.py` = serialisation donnees
+- ADR-002 est relaxe (4 -> 5 modules), pas invalide (le principe "un module = une responsabilite" reste)
+- Le module est independant de Rich (pas de dependance supplementaire)
+- Extensible pour CSV/YAML sans modifier l'existant
+
+## ADR-007 : Retry simple plutot que urllib3.Retry (v1.2.0)
+
+**Date** : 2026-03-12
+**Statut** : accepte
+
+**Contexte** : Les timeouts API causent un crash. Deux strategies : configurer `HTTPAdapter` avec `urllib3.Retry`, ou implementer un retry manuel dans le client.
+
+**Decision** : Retry manuel (boucle + time.sleep) dans `GiteaClient._get_with_retry()`. Maximum 2 retries, backoff lineaire (1s, 2s).
+
+**Consequences** :
+- Code explicite et testable (mock de `time.sleep`)
+- Pas de dependance sur l'API interne de urllib3
+- Applicable a tous les appels HTTP du client de maniere uniforme
+- Limite : pas d'exponential backoff (acceptable pour un outil CLI local)
+
+## ADR-008 : Tri dans display.py, pas dans collector.py (v1.2.0)
+
+**Date** : 2026-03-12
+**Statut** : accepte
+
+**Contexte** : Le tri des repos peut etre place dans le collecteur (donnees ordonnees) ou dans l'affichage (presentation ordonnee).
+
+**Decision** : Le tri est dans `display.py`. Le collecteur retourne les donnees dans l'ordre de l'API. L'affichage decide de l'ordre de presentation.
+
+**Consequences** :
+- Le collecteur reste un simple agregateur de donnees (SRP)
+- Le tri est teste independamment de la collecte
+- L'export JSON peut aussi appliquer le tri (via `_sort_repos` importable depuis display)
+- Le critere de tri par defaut ("name") garantit un affichage stable entre les executions