Contrat des actions et des capacités — Altifigence Documentation

Distinguez la découverte d’actions, les rapports de capacités installées, les contrôles préalables, l’exécution et l’autorité serveur.

Présentation

Le CLI fournit un manifeste d’actions, un contrôle préalable hors ligne, la découverte des capacités installées et des commandes natives explicites. Le bootstrap 0.1.9 crée l’organisation installée signée nécessaire aux capacités. Ces sorties répondent à des questions différentes ; aucune ne doit être considérée comme preuve des autres.

Manifeste d’actions client

Le manifeste versionné contient 25 actions :

22 actions sont marquées executes=true;
altifigence.analyze.run, altifigence.evolve.launch, et altifigence.verify.run sont les trois actions limitées à la planification.

executes=true signifie que l’action est définie comme exécutable. La commande réelle peut encore nécessiter un moteur local, une autorisation de compte ou un service distant. Une action limitée à la planification valide et renvoie un plan sans exécuter de tâche.

Utilisez alti commands pour inspecter le manifeste livré avec le binaire actuel. Ne copiez pas une liste de commandes d’une autre version.

Reçu de contrôle préalable hors ligne

Le workflow hors ligne job validate vérifie une enveloppe RTL CPU bornée et une source sûre relative à l’espace de travail. Un reçu réussi indique explicitement submitted: false et server_authority_verified: false. Il n’exécute pas de moteur local et ne contacte pas de service hébergé. Consultez Première réussite avec le CLI.

Contrat des capacités de moteur installées

Le schéma de capacités définit ces états pour une version correctement installée et accompagnée de reçus :

État	Signification
`real`	La version installée fournit la surface locale documentée
`partial`	Seul le sous-ensemble indiqué est disponible
`unavailable`	La version installée ne peut pas fournir la surface
`default-off`	La surface nécessite une autorisation explicite documentée
`plan-only`	L’action renvoie un plan plutôt qu’une preuve d’exécution

Suivez Vérifier les téléchargements et Installation sous Linux avant d’utiliser alti capabilities. Le bootstrap intégré crée l’organisation authentifiée du catalogue/des reçus ; ne copiez pas un binaire ailleurs et ne fabriquez pas cet état. La préparation installée indique les capacités disponibles. La preuve qu’une conception ou une tâche GPU a été exécutée provient de son résultat d’exécution.

Question	Réponse fournie par
Cette commande s’est-elle exécutée ici, et avec quel résultat ?	Le code de sortie propre à la commande et la ligne du reçu nommant le binaire, la résolution et l’état
Cette version installée indique-t-elle la capacité comme disponible ?	Un rapport réussi de `alti` `capabilities` sur une version installée

Une commande locale réussie indique ce qui s’est exécuté sur cette machine. Une automatisation dépendant d’une capacité de produit installée doit également exiger le rapport de capacité.

L’envoi des sources nécessite une autorisation

En mode client par défaut, le serveur MCP stdio fourni masque les trois actions de planification pouvant inclure des fichiers sources. Elles nécessitent des identifiants d’environnement distincts et utilisent le client Cloud. La version publique actuelle ne fournit pas pour elles de workflow complet d’exécution distante.

Le mode distinct ALTI_MCP_MODE=local-xls expose des outils XLS locaux fixes sans répartition Cloud. Les opérations natives ide cloud utilisent leur propre connexion et leurs règles explicites d’envoi ; l’état limité à la planification des actions client ne décrit pas toutes les opérations d’espace de travail Cloud.

Une autorisation permet la transmission ; elle ne transforme pas une action de planification en véritable exécution et ne rend pas un service distant disponible.

Traiter chaque résultat séparément

Lorsque vous automatisez le CLI, traitez ces résultats comme des états distincts :

une capacité locale est disponible ;
une requête a été validée ;
un plan a été renvoyé sans exécution ;
un travail a été accepté par une autorité explicitement activée ;
un travail s’est achevé et a produit des preuves ;
une capacité ou une autorité était indisponible.

Fusionner ces états en une seule valeur de réussite peut faire paraître un plan ou un aperçu comme un travail d’ingénierie achevé.

Sélectionner le bon contrat de résultat

Pour une exécution locale, consignez le moteur sélectionné, l’empreinte d’entrée, le code de sortie natif et le résultat complet. Pour une modification de fichier enregistré, conservez le plan et le reçu d’application, puis relisez le fichier. Pour une tâche distante, suivez son identifiant jusqu’à un état terminal, puis récupérez et vérifiez le résultat réel. Une entrée du manifeste d’actions décrit uniquement l’interface appelable.

Gardez distincts les enveloppes de requêtes des moteurs locaux, les actions client de planification et les tâches RTL Cloud enregistrées dans vos automatisations. Leurs schémas d’entrée, emplacements des sources, authentification, soumission et traitement des résultats diffèrent même lorsque leurs noms contiennent « analyze » ou « evolve ».