Générer des schémas de commandes pour agents IA à partir des vraies commandes et options

## Modifier le registre et les générateurs, pas les fichiers générés Traitez les consignes du dépôt comme un contrat pour les fichiers relevant de leur portée. Préservez les travaux sans rapport, appliquez l’outil de formatage du langage à chaque fichier source modifié et ne changez que la plus petite entrée responsable nécessaire au comportement demandé. Identifiez les entrées de référence avant toute modification. Un registre de commandes vérifié doit gérer l’identité stable des commandes, les chemins principaux, les alias et la navigation. L’arbre de commandes exécutable doit déterminer si un chemin existe, s’il est exécutable et quels indicateurs il accepte. Les catalogues générés et les métadonnées d’agents sont des sorties, pas des surfaces de modification ; changez leurs entrées sources et leurs générateurs, puis régénérez-les. Exécutez la compilation, la totalité des tests, la génération, les vérifications de dérive, les vérifications de politique et les tests de commandes ciblés définis par le dépôt qui couvrent le changement. Examinez la différence générée et rejetez les réécritures sans rapport. ## Construire les schémas dans un seul sens et lier chaque commande une fois Maintenez la résolution du schéma dans un seul sens : 1. Construisez l’arbre de commandes et les indicateurs réellement exécutables. 2. Combinez le registre d’identité vérifié avec les surcharges de métadonnées vérifiées avant la liaison. 3. Résolvez les types et les correspondances de paramètres, les états obligatoires, les valeurs par défaut et les contraintes entre paramètres. 4. Résolvez la sélection de l’agent ainsi que la sémantique de sécurité, d’interface et de barrières d’exécution selon la priorité déclarée des sources. 5. Liez chaque commande exactement une fois dans une spécification d’outil typée unique et un index. 6. Publiez les catalogues, les exportations complètes, les résumés et les métadonnées générées uniquement depuis cette source typée. Après la liaison, ne rouvrez pas les annotations, les enregistrements sources, les catalogues antérieurs ni le JSON généré pour réparer ou résoudre à nouveau l’identité. Un chargeur de production qui décode un instantané intégré est une limite de livraison, pas une deuxième étape de résolution des sources. Il ne doit jamais créer ni réparer des commandes, des indicateurs, des entrées de registre ou des entrées destinées à une génération ultérieure. Préservez le contrat de sérialisation publié, sauf si une modification versionnée est explicitement autorisée. Un alignement architectural avec un autre système ne justifie pas un changement de format non versionné. ## Vérifier dans les deux sens que commandes et schémas correspondent Le mécanisme de liaison doit rejeter un chemin de commande absent ou non exécutable, les collisions d’alias et les déclarations d’identité natives qui ne correspondent pas au registre effectif. Une déclaration d’identité native absente peut être autorisée lorsque les annotations sont des contrôles de cohérence et non des sources d’identité de remplacement. Imposez la couverture dans les deux sens : 1. Chaque outil de schéma livré, y compris sa projection dans le catalogue, doit se résoudre vers une commande exécutable. 2. Chaque feuille de commande publique et exécutable doit se résoudre vers le schéma ou figurer dans une exclusion exacte, vérifiée et accompagnée d’une raison non vide. N’utilisez jamais d’exclusions par préfixe ou caractère générique, car elles pourraient masquer de futures commandes. Les exclusions obsolètes, non valides ou en double doivent faire échouer la génération, et une exclusion doit être retirée dès que sa commande entre dans le schéma. Traitez le registre vérifié comme l’unique source d’identité stable et de navigation, et l’arbre exécutable comme la source de vérité pour les chemins, l’exécutabilité et les indicateurs. Exécutez des tests de complétude inverse à chaque modification de l’arbre de commandes. ## Séparer les métadonnées de sécurité des textes de sélection de l’agent Répartissez les entrées rédigées par des personnes selon leur responsabilité. Les métadonnées gèrent les effets, le risque, la confirmation, l’idempotence, les interfaces, les barrières d’exécution et les surcharges facultatives de paramètres. La sélection gère les résumés destinés aux agents, les consignes de routage positives et négatives, les exemples et le routage des produits. Un index doit uniquement associer les identifiants de produits à ces fichiers. Ne mélangez pas les champs entre ces blocs. Chaque entrée rédigée doit être explicitement vérifiée, comprendre un motif concret de vérification et des références d’éléments de preuve, et constituer la plus petite entrée exprimant le comportement visible par l’utilisateur. Le texte de sélection doit expliquer l’intention de déclenchement, le routage entre commandes apparentées et les résultats attendus, au lieu de répéter le résumé d’une commande. Résolvez les éléments de preuve selon la priorité déclarée : d’abord les faits d’exécution, puis le schéma d’interface actif, les métadonnées d’interface figées et, enfin, la documentation de compétences uniquement comme preuve. Lorsque la découverte active utilise des identifiants personnels, n’affichez et n’intégrez jamais les identifiants d’accès à un commit. Si la découverte active échoue, consignez l’échec, utilisez les preuves de remplacement approuvées et n’inventez ni interface ni procédure distante. Les surcharges de paramètres doivent cibler exactement une feuille publique et exécutable et des indicateurs réels. Elles peuvent préciser les descriptions, les correspondances d’interface, les états obligatoires et les exigences conditionnelles, mais elles ne doivent pas créer de commandes ou d’indicateurs, définir une interface ni annoncer une procédure distante inconnue. ## Tout régénérer depuis zéro et vérifier que les sorties concordent Traitez la génération comme une reconstruction complète et déterministe de l’instantané, et non comme un correctif incrémental appliqué à un catalogue antérieur. Relisez chaque entrée vérifiée, retirez les métadonnées générées de produits devenues obsolètes et réécrivez les projections de sortie exactes. Les fichiers générés ne doivent jamais devenir des entrées de fusion, et les protections au niveau des octets doivent échouer si la génération modifie des entrées rédigées ou le registre vérifié. Utilisez la même spécification d’outil typée résolue pour chaque projection. La charge utile d’une feuille doit être égale à son entrée correspondante dans l’exportation complète et le catalogue, tandis que les résumés généraux et de groupe doivent être égaux à la projection résumée du même outil. Une recherche par alias ne peut modifier que les champs d’affichage propres à l’alias ; elle ne doit ni résoudre à nouveau ni modifier le contrat de la commande. Pour chaque outil et champ de paramètre livrés, la valeur de provenance sélectionnée doit être exactement égale à la valeur livrée. Vérifier uniquement le nom de la source, le nombre de candidats, la présence du champ ou le hachage ne suffit pas. Exécutez la génération, les contrôles de véracité de la confirmation à l’exécution, les tests de complétude inverse, les tests de commandes ciblés et les contrôles finaux du chargeur intégré. Examinez toutes les différences obtenues avant d’accepter l’instantané. ## Valider exemples et exécutions à blanc sans saut ni --yes Conservez au maximum deux exemples vérifiés par outil. Les exemples doivent utiliser un chemin principal ou un alias réel, des indicateurs acceptés, les arguments positionnels obligatoires et toutes les contraintes effectives `require-one-of`, `require-together` et `mutual-exclusion`. N’incluez pas de commentaires d’interpréteur de commandes ni d’indicateurs contournant la confirmation, comme `--yes`. Chaque exemple doit réussir la validation du contrat par rapport à sa commande liée. Une valeur obligatoire absente, une contrainte non respectée, une erreur d’exécution ou une erreur de résolution d’interface constitue un défaut du contrat, et non une raison d’ignorer l’exemple. L’exécution d’exemples en conditions réelles est facultative et autorisée uniquement lorsque l’outil typé final publie une capacité explicite et vérifiée d’exécution à blanc. Les métadonnées de risque et de confirmation ne doivent pas fabriquer une prise en charge des aperçus. Une décision manuelle vérifiée peut limiter une capacité d’exécution à blanc existante à un index d’exemple exact commençant à zéro, mais elle doit utiliser un code de motif approuvé, fournir un motif concret et ne jamais transformer une validation ordinaire du contrat en omission. N’interceptez jamais l’échec d’une exécution à blanc pour le rétrograder dynamiquement en validation du contrat uniquement. Exécutez par défaut des barrières contractuelles exhaustives ; avec la commande réelle, n’exécutez que le sous-ensemble admissible d’exécutions à blanc, avec un état utilisateur isolé et des serveurs mandataires bloqués. Traitez les changements des nombres d’exécutions stables comme des changements de contrat soumis à vérification. ## Tester quelle commande l’IA choisit sans lui envoyer les réponses attendues Traitez chaque scénario de sélection positif comme une affirmation selon laquelle sa commande vérifiée doit être choisie, et chaque scénario négatif comme une affirmation selon laquelle cette commande ne doit pas être choisie. Dérivez des cas de test typés et déterministes des champs de sélection rédigés, exigez une couverture exacte des outils et des commandes principales exécutables, et rejetez les attentes absentes, en double ou contradictoires. La seule correspondance de chaînes ne prouve pas la compréhension sémantique. Maintenez explicitement facultatifs les contrôles de sélection utilisant un modèle actif. Prenez en charge un petit ensemble de contrôle, un ensemble vérifié complet et une liste exacte de cas. Envoyez uniquement les identifiants de cas, le texte du scénario et une table de candidats du même produit à l’évaluateur ; conservez localement les affirmations attendues et interdites. Inscrivez les points de terminaison HTTPS intégrés de l’évaluateur dans la liste d’autorisation. Tout autre fournisseur HTTPS exige que son URL de base exacte figure dans la liste approuvée, et le HTTP en clair n’est acceptable que pour un serveur de test en boucle locale. N’envoyez jamais d’identifiants d’API à un point de terminaison arbitraire en clair. L’intégration continue normale doit rester déterministe et ne doit appeler aucun modèle. Ses barrières bloquantes sont les cas de test reproductibles, la liaison des commandes, la validité des exemples, la provenance et l’égalité de la livraison finale. ## Fixer sécurité et confirmation selon la priorité des sources Résolvez les métadonnées de sécurité et de paramètres selon la priorité des sources, et non en choisissant la valeur qui semble la plus stricte. Une source vérifiée de priorité supérieure peut augmenter ou diminuer volontairement l’effet, le risque, la confirmation, l’idempotence, les descriptions ou les correspondances. Préservez tous les candidats et la source sélectionnée, et faites échouer les conflits de même priorité au lieu de les fusionner silencieusement. Les indicateurs obligatoires d’une commande constituent une limite inférieure inaltérable : une surcharge peut rendre obligatoire un indicateur facultatif, mais elle ne doit jamais affaiblir une exigence déclarée par la commande exécutable. Pour le texte des commandes, privilégiez les consignes vérifiées propres à la commande, puis l’aide de la commande et enfin les métadonnées d’interface ; un texte générique de procédure distante ne doit pas remplacer une description spécialisée de la commande. Ne déduisez pas un champ de sécurité à partir d’un autre. Un effet destructeur ou un risque élevé ne réécrit pas mécaniquement la confirmation. La confirmation doit correspondre à la barrière d’exécution explicite et, lorsqu’une confirmation de l’utilisateur est requise, elle doit être obtenue avant d’ajouter un indicateur de contournement tel que `--yes`. Si l’aide de commande livrée et le schéma de feuille divergent, ne transmettez que les indicateurs acceptés par la commande exécutable. Si les sources de sécurité sont en conflit, utilisez l’interprétation la plus sûre ou arrêtez-vous et signalez la dérive du contrat. Vérifiez la sémantique de confirmation au moyen du chargeur intégré final et du chemin de requête, et pas uniquement dans un test unitaire du générateur. ## Découvrir les commandes par étapes, puis lire les données avec de vraies commandes Maintenez la découverte ordinaire progressive : d’abord la vue d’ensemble, puis le produit ou le groupe, et enfin la feuille. Réservez l’exportation complète comme contrat de compatibilité stable et incluez les paramètres, les contraintes et la sémantique de sécurité complets pour chaque outil final, y compris un objet de paramètres vide pour les commandes sans indicateur. Une exportation complète compacte ne constitue pas une référence de compatibilité complète. L’aide de commande détermine si un chemin existe et quels indicateurs l’exécutable accepte. Le schéma de feuille détermine la sélection de l’agent, la correspondance et les contraintes des paramètres, ainsi que la sémantique de sécurité et de confirmation. Toute divergence est une dérive du contrat, et non une autorisation de deviner. Les schémas et l’aide décrivent les commandes ; ils ne renvoient pas de données métier. Après la découverte, exécutez la commande réelle appropriée de lecture, de recherche ou de liste dans le cadre de ses autorisations confirmées afin d’obtenir les données. Avant la livraison, confirmez que l’identité des commandes est vérifiée, que la couverture exécutable est bidirectionnelle, que les exclusions sont exactes, que les blocs rédigés conservent des responsabilités séparées, que la priorité des sources est préservée, que les sorties générées restent uniquement des sorties, que les exemples respectent leurs contrats réels, que la confirmation correspond aux barrières d’exécution et que chaque projection est égale à la même source typée.