# TODO

## Priorité haute

### 1. Définir une politique d'exécution et de gestion d'erreur explicite
- Documenter ce qui est considéré comme fatal vs best-effort
- Définir si la séquence d'actions d'un hôte doit continuer après un échec
- Standardiser les codes de sortie
- Aligner le comportement réel, l'aide CLI et le README

### 2. Sécuriser les zones sensibles de construction de commandes SSH
- Revoir les zones de quoting encore fragiles
- Prioriser `cmd:<...>` et `docker-stacks:<...>`
- Documenter des cas de test manuels pour les commandes avec espaces, pipes, redirections, `&&`, `||` et arguments quotés
- Réduire le risque de régressions lors des prochains durcissements

## Priorité moyenne

### 3. Améliorer le mode semi-automatisé / non interactif
- Ajouter de vraies options batch-friendly, par exemple :
  - `--all`
  - `--no-log-view`
  - `--keep-log`
  - `--log-path <path>`
- Clarifier la différence entre préselection interactive (`-f`) et exécution réellement non interactive

### 4. Ajouter un minimum de validation et de qualité shell
- Ajouter de la guidance ShellCheck dans le projet
- Envisager `shfmt` si cela reste léger
- Ajouter des vérifications simples autour des fichiers de configuration sourcés
- Rester incrémental, sans imposer brutalement un strict mode global

### 5. Réduire progressivement la complexité du script principal
- Extraire des helpers quand cela réduit la duplication sans casser le comportement
- Simplifier les branches liées aux package managers
- Garder des changements petits et relisibles

## Priorité basse

### 6. Réfléchir à une configuration plus sûre si le projet grossit
- Le sourcing Bash reste acceptable tant que le modèle est assumé
- Si le projet s'étend, envisager à terme un format déclaratif plus sûr

### 7. Introduire des tests ciblés
- Prioriser les tests de parsing
- Ajouter des tests de construction de commandes
- Couvrir les régressions connues autour du quoting SSH
- Commencer petit plutôt que viser immédiatement une grosse suite end-to-end

## Rappels de conduite
- Préserver la compatibilité des fichiers de configuration existants autant que possible
- Préférer de petits commits logiques
- Traiter la cohérence documentation/comportement comme un sujet fonctionnel
- Être particulièrement prudent sur toute modification du quoting ou des commandes distantes