Commandes accessibles de la CLI

Présentation

Cette page répertorie la CLI native, le manifeste des actions client et les connexions propres à chaque backend. Utilisez Commandes Engine pour les travaux de conception locaux et Commandes de tâches et Cloud pour les opérations de service. Les exemples concernent l’interface 0.1.9.

Deux parseurs, un seul binaire

Le parseur natif gère release, capabilities, rtl, sv, verification, trace, labs, tcl, eidb, eda, reports, physical, px, isa, ide, job, xls et compute. Il gère également analyze run et les formes Evolve explicites capabilities, analyze, run, cx-search, measured-ppa et artifact. Les autres commandes client utilisent le manifeste d’actions intégré. mcp serve démarre le serveur MCP stdio.

Ce que ce routage exclut

eda inspect, reports parse, ide init et les formes Evolve répertoriées sont des commandes routées vers le parseur natif. Leur disponibilité n’est plus limitée par les omissions de dispatch de l’ancienne archive. Les capacités du moteur déterminent toujours quelles entrées ou opérations sont prises en charge.

L’action client en un mot evolve est distincte des commandes natives evolve run et compute rtl-evolve. Leurs schémas de requête ne sont pas interchangeables. L’action en un mot trace du manifeste reste masquée par l’espace de noms natif trace ; utilisez les sous-commandes natives plutôt que de supposer que l’énumération du manifeste garantit une syntaxe CLI correspondante.

Options globales

Placez --json en tête pour obtenir une sortie native structurée, par exemple alti --json xls capabilities. Placez l’option avant l’espace de noms ou après la sous-commande native complète, pas entre les mots d’une forme Evolve routée. Utilisez alti --help pour le résumé général et --help sur l’opération finale pour connaître les arguments acceptés et les limites. Les commandes natives finales acceptent également -h.

La sortie JSON dépend de la commande. Les enveloppes Engine contiennent le résultat du processus enfant sous forme de chaîne, les commandes de service renvoient des justificatifs et les attachements de terminal diffusent des octets. Voir Référence des commandes.

Commandes méta et de compte

Les sessions Cloud et les anciens identifiants d’accès d’environnement sont distincts. Voir Authentification de la CLI.

Codes de sortie

Traitez tout résultat non nul comme un échec, sauf si le contrat de la commande définit une action de récupération. L’analyse/admission renvoie couramment 2, les échecs runtime et HTTP 1, les moteurs indisponibles 127 et l’exécution installée invalide ou les échecs de lancement 126. Les moteurs peuvent transmettre leurs propres codes d’état. Le manifeste client utilise séparément 3 pour un rejet de classe et 4 pour un refus avant dispatch. Un numéro d’état seul n’identifie pas son origine.

Où s’exécutent les opérations

Quelles sous-commandes acceptent –runner

Les commandes de compatibilité rtl compile, rtl synthesize, physical run, px analyze et isa run utilisent par défaut local. Choisir cloud ou private sur ces commandes produit un plan de dispatch de squelette ; ce n’est pas une exécution distante. Leurs arguments de moteur -- ne sont acceptés que pour le dispatch local.

Dans la famille job, l’option --runner sélectionne un Job Service et relève d’un contrat différent. L’ancien adaptateur alti-engine-job n’est pas dans l’inventaire des 24 exécuteurs de la version ; n’interprétez pas l’acceptation de la syntaxe local/private comme un service livré.

Comment un moteur local est trouvé

Conservez l’installation de la version intacte. XLS, compute, RTL empaqueté, DDS natif et les parcours PX/CX typés exigent leur exécutable compagnon nommé. Le contrôle de confiance installé lie les exécuteurs protégés aux empreintes du catalogue et aux justificatifs ; aucun repli PATH ni justificatif fourni par l’utilisateur ne répare cette limite. Les anciens résolveurs de compatibilité peuvent signaler sibling ou path ; inspectez le justificatif de l’opération réellement exécutée. Les outils externes tels qu’Icarus ont une configuration d’hôte distincte.

Quel moteur alimente quel espace de noms

La charge utile contient alti et alti-mcp ainsi que ces 24 exécuteurs de moteur :

alti-rtl-runner n’est pas empaqueté. Les commandes de compatibilité d’identité validée qui le demandent ne deviennent pas prises en charge du seul fait de l’existence de leur aide. L’exécutable de bureau utilisé par ide open est distribué séparément.

Enveloppes de justificatifs

Le champ stdout d’une enveloppe Engine est une chaîne contenant le résultat natif. Sans --json, cette sortie native peut être enregistrée directement et transmise intacte à une commande DDS apply correspondante. Ne réduisez jamais un plan de création à sa seule empreinte.

Variables d’environnement

Cloud natif utilise --session-dir, avec pour valeur par défaut ~/.local/state/altifigence/cloud-cli. N’y copiez pas les fichiers de session de bureau, ne consignez pas les jetons et n’envoyez pas de secrets de service à des endpoints arbitraires.

Résultats des moteurs

Lisez le résultat réel du moteur et ses limites. La découverte d’un GPU n’est pas une exécution GPU, une empreinte de contenu n’est pas une signature et une estimation temporelle sans signoff n’est pas une validation finale d’implémentation. La page suivante répertorie les commandes de moteur.

Résoudre une commande avant de l’utiliser dans un script

alti --version
alti --help
alti ide cloud --help
alti xls run --help

Vérifiez l’aide de l’opération finale exacte que vous comptez appeler. Un nom correspondant dans alti commands ne remplace pas l’aide du parseur natif, les capacités installées ni la disponibilité du runtime. Conservez la version de la CLI avec les scripts, car les schémas de requête et les justificatifs sont versionnés.