chore: rename repository state file to STATE.md

TODO.md

@@ -0,0 +1,54 @@
+# 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