docs: reorganize TODO priorities
This commit is contained in:
@@ -2,51 +2,30 @@
|
||||
|
||||
## 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
|
||||
### 1. 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
|
||||
### 1. 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
|
||||
### 2. 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
|
||||
### 1. 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
|
||||
|
||||
Reference in New Issue
Block a user