Lancer un outil CLI complexe depuis des scripts et vérifier la réussite dans son rapport JSON

## Juger la réussite de la CLI sur des données structurées, pas sur le texte de progression Lorsqu’un script, une chaîne de traitement ou un agent de programmation pilote un outil complexe en ligne de commande, traitez la CLI comme une interface machine versionnée et non comme un interpréteur interactif. Séparez la planification, l’exécution et la vérification afin que chaque étape consomme des données structurées et produise des preuves que l’étape suivante peut valider. - N’analysez pas le texte de progression destiné aux humains pour décider si une exécution a réussi. - Ne déduisez pas de mémoire les tâches prises en charge, les classes de sortie ni les exigences de licence. - Consignez la version de l’outil, les paramètres d’exécution résolus, le périmètre demandé et les artefacts produits. - Refusez la réussite par défaut lorsque les preuves structurées obligatoires sont absentes ou incohérentes. ## Lister les tâches et classes de l’outil avant de planifier Utilisez la commande légère d’information ou de registre de l’outil avant de construire un traitement coûteux. Préférez une vue JSON générée depuis le même registre que celui qui valide la CLI principale, car les listes copiées depuis le code source et les noms inscrits en dur peuvent diverger de la version installée. La découverte doit fournir : - les tâches disponibles et leur modalité d’entrée ; - l’indication qu’une tâche nécessite ou non une licence ou un droit d’accès ; - la correspondance exacte entre indices et noms de classe acceptée par les filtres de classes ; - la version installée de l’outil et les contraintes propres à chaque tâche. Préférez un chemin de découverte qui ne charge pas de lourdes dépendances d’inférence, n’initialise pas d’accélérateur, ne télécharge pas de poids de modèle et ne modifie pas l’état local. Limitez la requête à une tâche ou à une vue des classes lorsque le registre complet n’est pas nécessaire. ## Indiquer toutes les entrées, sorties et options pour pouvoir refaire l’exécution Construisez chaque exécution à partir de valeurs explicites : entrée, sortie, tâche, politique de périphérique, sous-ensemble facultatif de classes, représentation de la sortie et chemin du rapport. N’acceptez que les formes d’entrée documentées, telles qu’un fichier de volume, un répertoire de coupes ordonnées ou une archive de coupes, puis validez la destination choisie par rapport au mode de sortie sélectionné. Avant l’exécution : 1. Confirmez que la tâche et les classes demandées existent dans le registre de capacités actuel. 2. Confirmez que la forme d’entrée est prise en charge et que le chemin de sortie est sans ambiguïté. 3. Réglez la question de la licence avant de lancer une tâche soumise à autorisation. 4. Choisissez délibérément le périphérique et le mode de performance. 5. Réservez un chemin unique pour le rapport d’exécution lisible par machine. Ne réutilisez pas un répertoire de sortie si d’anciens artefacts risquent d’être confondus avec les résultats actuels. Conservez les paramètres résolus de la commande avec les preuves de l’exécution. ## Choisir le périphérique et le mode rapide, et vérifier la licence avant une tâche qui l’exige Traitez la sélection du périphérique et les options de vitesse comme des éléments du contrat de reproductibilité. Consignez le périphérique effectivement résolu, pas seulement celui qui a été demandé, car une accélération indisponible peut provoquer un repli sur le processeur et modifier sensiblement la durée d’exécution. Lorsque les ressources sont limitées, réduisez le coût à l’aide de réglages documentés : - utilisez un mode rapide à plus faible résolution lorsque la perte de précision est acceptable ; - ne demandez que les classes nécessaires au traitement ultérieur ; - indiquez un indice d’accélérateur précis lorsque plusieurs périphériques sont disponibles ; - sélectionnez explicitement le moteur de plateforme pris en charge lorsque cela est nécessaire. Ne remplacez jamais silencieusement le mode demandé par un mode plus rapide ou plus restreint s’il modifie la qualité ou le périmètre du résultat. Si une tâche exige une licence, arrêtez-vous avant l’inférence, sauf si une autorisation valide est déjà configurée. ## Vérifier le rapport JSON et chaque fichier qu’il liste Exigez que la CLI écrive un rapport structuré après une exécution réussie. Ce rapport constitue l’artefact de transmission faisant autorité pour l’automatisation et doit contenir : - les versions de l’outil, de l’environnement d’exécution, du cadre logiciel et des dépendances ; - la tâche, la modalité et l’exigence de licence ; - le périphérique résolu et les indicateurs de performance ; - les emplacements normalisés d’entrée et de sortie ; - le sous-ensemble de classes demandé et la correspondance finale entre indices et noms de classe ; - la durée réelle d’exécution et la liste exacte des fichiers de sortie produits. Vérifiez que le rapport existe, peut être analysé comme du JSON, identifie la tâche attendue et répertorie tous les artefacts nécessaires à l’étape suivante. Vérifiez ensuite l’existence de chaque fichier répertorié. Utilisez des résultats statistiques dédiés pour le volume, l’intensité, le nombre de voxels, la dispersion, les valeurs extrêmes, les centroïdes ou les boîtes englobantes de chaque classe ; ne déduisez pas ces valeurs des noms de fichiers ni du texte de progression. ## Trier les échecs par code de sortie et réessayer dans un nouveau dossier Interprétez l’état de sortie du processus avant de lire tout artefact facultatif. Distinguez l’achèvement réussi, l’échec à l’exécution et l’échec d’argument ou d’utilisation afin que les nouvelles tentatives ne répètent pas des commandes invalides. - En cas de réussite, validez le rapport et les fichiers de sortie déclarés. - En cas d’échec à l’exécution, capturez l’erreur standard de diagnostic et classez les causes, par exemple une autorisation absente, des ressources indisponibles, une entrée corrompue ou une erreur d’outil non gérée. - En cas d’échec d’argument, corrigez la tâche, l’entrée, la sortie ou l’ensemble d’options avant de réessayer. - Utilisez le mode silencieux pour réduire le bruit courant et le mode de débogage uniquement lorsqu’un contexte de diagnostic supplémentaire est nécessaire. Ne considérez pas des fichiers partiels, un message de progression ou un répertoire de sortie vide comme une réussite. Une nouvelle tentative doit utiliser une destination nouvelle ou nettoyée afin que les artefacts de la tentative échouée ne puissent pas satisfaire la vérification. ## Passer par l’API publique et enchaîner la suite avec la liste de fichiers du rapport Utilisez l’API de programmation de haut niveau prise en charge lorsqu’une exécution dans le même processus est nécessaire, tout en conservant le même contrat explicite de tâche, d’entrée, de sortie et de vérification que pour le flux de la CLI. Pour la planification et la validation, préférez un module de registre léger capable d’énumérer les tâches et les classes sans importer tout l’environnement d’inférence. Maintenez l’orchestration indépendante des détails internes de mise en œuvre : découvrez les capacités depuis le registre officiel, exécutez par la CLI ou l’API documentée et enchaînez le traitement ultérieur à partir de la liste des sorties du rapport structuré. Cela préserve l’automatisation entre les versions tout en évitant l’analyse fragile de la sortie standard et la duplication des tables de capacités.