Référence des commandes CLI

Présentation

Utilisez le binaire installé après vérification et installation. Cette référence distingue la découverte des commandes, les résultats d’exécution, les justificatifs de contrôle préalable et les réponses des services.

Manifeste des actions

En cas de réussite, un tableau JSON unique est écrit. Chaque entrée comporte name, description, inputSchema, executes et class. Le manifeste client intégré comporte 25 actions, dont 22 ont executes: true. altifigence.analyze.run, altifigence.evolve.launch et altifigence.verify.run. Les sous-commandes natives de la CLI possèdent leur propre aide finale au-delà de ce manifeste client. La réponse du serveur détermine si une opération de service est autorisée et prête.

Utilisez l’aide de l’opération finale pour les arguments natifs :

alti commands

alti xls upstream run --help
alti compute rtl-evolve --help
alti ide workspace hierarchy-plan --help
alti ide cloud search --help
alti ide service workspace replace --help

Contrôle préalable hors ligne des tâches

Préparez la source et l’enveloppe dans Premier succès avec la CLI, puis exécutez :

Le schéma de réussite est altifigence.cli.engine-job-preflight.v1. submitted: false et server_authority_verified: false sont requis : l’empreinte source et la structure de la tâche ont été vérifiées localement, mais aucune tâche n’a été soumise ou exécutée. Le execution_placement demandé par une enveloppe ne change pas cela.

alti --json job validate \
  --job "$ALTI_WORKSPACE/job.json" \
  --workspace-root "$ALTI_WORKSPACE" \
  --source rtl/top.sv

Contrat d’erreur JSON

Un --json job validate en échec n’écrit aucun justificatif de réussite sur stdout et émet un objet altifigence.cli.error.v1 sur stderr :

Utilisez error.code lorsqu’il est disponible. Les autres familles de commandes ont leurs propres schémas d’erreur ; ne supposez pas que cette enveloppe s’applique à toute commande CLI.

{
  "schema": "altifigence.cli.error.v1",
  "error": {
    "code": "ENGINE_JOB_JSON_INVALID",
    "message": "The engine job JSON is invalid.",
    "retryable": false
  }
}

Code de sortie

Vérifiez toujours le code de sortie avant d’analyser stdout et gardez stderr séparé. Un fichier de sortie vide ou partiel n’est pas un résultat réussi. Un plan enregistré n’est pas une transaction appliquée, et une acceptation par le serveur n’est pas une tâche terminée.

Commandes Engine : ce qui s’exécute réellement

Les adaptateurs XLS, compute et DDS natif utilisent des exécutables compagnons fixes empaquetés. L’exécution installée authentifie l’exécuteur concerné par rapport à son enregistrement de version signé ; ajouter un autre exécutable au PATH ne répare pas l’absence d’un compagnon requis. Certaines anciennes commandes de compatibilité conservent le comportement documenté de leur résolveur. Voir Commandes accessibles.

Sans --json, stdout du moteur est transmis pour qu’un plan natif opaque puisse être enregistré directement. Avec --json, un appel de moteur produit normalement altifigence.local-engine-execution.v1 ; ses champs stdout et stderr contiennent les flux du processus enfant sous forme de chaînes. Analysez le résultat interne séparément.

Pour les plans de fichiers et de hiérarchie, transmettez le résultat complet du plan natif à la commande apply correspondante. Ne transmettez pas l’enveloppe CLI externe ni la seule empreinte du plan. Le backend natif valide les empreintes actuelles des fichiers et les conditions de sa transaction.

Sorties de service et flux

ide service renvoie altifigence.dds.service-receipt.v1 avec operation, ok, httpStatus et la réponse bornée body. Le code HTTP 409 d’un remplacement reste un conflit et ne fait pas l’objet d’une nouvelle tentative. Une réponse DELETE réussie vide reste vide ; elle n’est pas transformée artificiellement en objet JSON serveur.

La recherche DDS native et la recherche Cloud exposent leurs propres preuves de correspondance/contenu. Utilisez l’identité fournie par le backend sur lequel vous écrirez ; une empreinte calculée pour un autre backend de recherche n’est pas automatiquement un jeton CAS valide.

ide cloud terminal diffuse les octets du terminal sur stdout et l’état de connexion sur stderr. Ce n’est pas un justificatif JSON unique, même avec l’option globale --json. Limitez la durée de l’attachement et conservez le curseur si vous comptez vous reconnecter.

--json release install et --json release uninstall émettent altifigence.cli.release-bootstrap.v1 avec operation, ok et exitCode. Les diagnostics d’installation sont envoyés sur stderr. Des échecs de vérification ou de privilège peuvent survenir avant qu’une enveloppe de réussite existe.

Capturer un résultat pour l’automatisation

Sélectionnez un nouveau répertoire de sortie pour chaque appel. Enregistrez stdout et stderr séparément, capturez immédiatement le code de sortie et n’analysez un schéma de réussite qu’après un code zéro. Avec une enveloppe Engine, analysez sa chaîne stdout comme document natif uniquement lorsque le contrat de la commande indique qu’elle contient du JSON.

Pour un workflow plan/apply, conservez le plan natif brut complet et utilisez le même projet. Examinez les fichiers concernés et leurs empreintes actuelles avant apply. Un conflit exige une nouvelle lecture et un plan revu ; il ne justifie pas de supprimer les contrôles d’empreinte. Voir Automatisation et CI pour un contrôle local reproductible.