netupgrade/TODO.md

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