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

3 phases: corrections/robustesse (#11,#12), tests edge (#13), features (#14,#15)
ADR-009 (retry 429), ADR-010 (sanitize JSON), ADR-011 (--health flag)

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

docs/technical/ARCHITECTURE.md

@@ -102,6 +102,7 @@ gitea-dashboard/
       v1.0.0-plan.md                # Plan de version
       v1.1.0-plan.md                # Plan de version
       v1.2.0-plan.md                # Plan de version
+      v1.3.0-plan.md                # Plan de version
     technical/
       ARCHITECTURE.md                # Ce fichier
       decisions.md                   # ADR
@@ -154,3 +155,8 @@ Decisions cles pour v1.2.0 :
 - **ADR-006** : Ajout du module exporter.py (5 modules)
 - **ADR-007** : Retry simple plutot que urllib3.Retry
 - **ADR-008** : Tri dans display.py, pas dans collector.py
+
+Decisions cles pour v1.3.0 :
+- **ADR-009** : Retry HTTP 429 avec Retry-After dans _get_with_retry
+- **ADR-010** : Sanitisation des caracteres de controle dans exporter.py
+- **ADR-011** : --health comme commande alternative, pas sous-commande

docs/technical/decisions.md

@@ -123,3 +123,47 @@
 - 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
+
+## ADR-009 : Retry HTTP 429 avec Retry-After dans _get_with_retry (v1.3.0)
+
+**Date** : 2026-03-12
+**Statut** : accepte
+
+**Contexte** : Le retry dans `_get_with_retry` ne gere que `requests.Timeout`. Un HTTP 429 (rate limiting) retourne une reponse HTTP, pas une exception Timeout. Le retry ne se declenche donc pas sur rate limiting.
+
+**Decision** : Etendre `_get_with_retry` pour intercepter les reponses HTTP 429. Respecter le header `Retry-After` (en secondes) si present, sinon utiliser le backoff lineaire standard. Apres epuisement des retries, lever `requests.HTTPError`.
+
+**Consequences** :
+- La logique de retry reste centralisee dans une seule methode (coherent avec ADR-007)
+- Le header Retry-After est un standard HTTP (RFC 7231), le respecter evite les retries inutiles
+- La boucle gere desormais 2 cas (Timeout + 429), complexite accrue mais testable
+- Pas de changement d'interface publique
+
+## ADR-010 : Sanitisation des caracteres de controle dans exporter.py (v1.3.0)
+
+**Date** : 2026-03-12
+**Statut** : accepte
+
+**Contexte** : L'export JSON peut contenir des caracteres de controle ASCII (0x00-0x1F) provenant des descriptions de repos. Ces caracteres sont invalides en JSON (RFC 8259) et causent des erreurs avec `python3 -m json.tool`.
+
+**Decision** : Sanitiser les champs texte dans `repos_to_dicts()` avant serialisation. Supprimer les caracteres de controle sauf `\n`, `\r` et `\t` (qui sont echappes nativement par `json.dumps`).
+
+**Consequences** :
+- La sanitisation est au point de sortie (exporter), pas dans le collecteur
+- Les donnees dans RepoData restent brutes (pas de perte pour le rendu Rich)
+- Approche defensive contre les donnees inattendues de l'API Gitea
+
+## ADR-011 : --health comme flag optionnel, pas sous-commande (v1.3.0)
+
+**Date** : 2026-03-12
+**Statut** : accepte
+
+**Contexte** : L'option `--health` est un mode alternatif au dashboard. Deux approches : flag optionnel ou sous-commande.
+
+**Decision** : Utiliser un flag `--health` dans argparse. Pas de sous-commandes.
+
+**Consequences** :
+- Coherent avec ADR-004 (argparse simple)
+- Un seul niveau d'arguments
+- `--health` est mutuellement exclusif avec le mode dashboard
+- Si d'autres modes alternatifs apparaissent, reconsiderer les sous-commandes