CLI-Befehlsoberfläche

Überblick

Diese Seite erschließt die native CLI, das Kundenaktionsmanifest und Backend-spezifische Verbindungen. Verwenden Sie Engine-Befehle für lokale Designarbeit und Job- und Cloud-Befehle für Dienstvorgänge. Die Beispiele gelten für die Oberfläche von 0.1.9.

Zwei Parser, ein Binary

Der native Parser verarbeitet release, capabilities, rtl, sv, verification, trace, labs, tcl, eidb, eda, reports, physical, px, isa, ide, job, xls, und compute. Er verarbeitet außerdem analyze run und die ausdrücklichen Evolve-Formen capabilities, analyze, run, cx-search, measured-ppa, und artifact. Die übrigen Kundenbefehle verwenden das eingebettete Aktionsmanifest. mcp serve startet den Stdio-MCP-Server.

Was diese Weiterleitung ausschließt

eda inspect, reports parse, ide init, und die aufgeführten Evolve-Formen sind weitergeleitete native Befehle. Ihre Verfügbarkeit wird nicht mehr durch die Dispatch-Auslassungen des älteren Archivs eingeschränkt. Engine-Fähigkeiten bestimmen weiterhin, welche Eingabe oder Operation unterstützt wird.

Die einwortige Kundenaktion evolve ist getrennt von nativem evolve run und compute rtl-evolve. Ihre Anfrageschemas sind nicht austauschbar. Die einwortige Manifestaktion trace bleibt vom nativen Namensraum trace verdeckt; verwenden Sie native Unterbefehle, statt anzunehmen, dass eine Manifestauflistung eine passende CLI-Schreibweise garantiert.

Globale Flags

Verwenden Sie ein vorangestelltes --json für native strukturierte Ausgabe, zum Beispiel alti --json xls capabilities. Platzieren Sie es vor dem Namensraum oder nach dem vollständigen nativen Unterbefehl, nicht zwischen den Wörtern einer weitergeleiteten Evolve-Form. Verwenden Sie alti --help für die Übersicht auf oberster Ebene und --help beim konkreten Vorgang für akzeptierte Argumente und Grenzen. Native Endbefehle akzeptieren außerdem -h.

JSON-Ausgabe ist befehlsspezifisch. Engine-Envelopes enthalten das Kindprozessergebnis als Zeichenfolge, Dienstbefehle liefern Nachweise zurück und Terminalanbindungen streamen Bytes. Siehe Befehlsreferenz.

Meta- und Kontobefehle

Cloud-Sitzungen und ältere Umgebungszugangsdaten sind getrennt. Siehe CLI-Authentifizierung.

Exit-Codes

Behandeln Sie jedes Ergebnis ungleich null als Fehler, sofern der Vertrag des jeweiligen Befehls keine Wiederherstellungsaktion definiert. Parsing/Zulassung liefert häufig 2, Laufzeit- und HTTP-Fehler 1, nicht verfügbare Engines 127 und ungültige installierte Ausführung oder Startfehler 126. Engines können ihre eigenen Statuswerte durchreichen. Das Kundenmanifest verwendet separat 3 für Klassenablehnung und 4 für Ablehnung vor dem Dispatch. Eine Statuszahl allein identifiziert ihre Herkunft nicht.

Was wo ausgeführt wird

Welche Unterbefehle –runner verwenden

Die Kompatibilitätsbefehle rtl compile, rtl synthesize, physical run, px analyze, und isa run verwenden standardmäßig local. Die Auswahl von cloud oder private bei diesen Befehlen erzeugt einen Dispatch-Plan als Gerüst; das ist keine Remote-Ausführung. Ihre ---Engine-Argumente werden nur für lokalen Dispatch akzeptiert.

Bei der job-Familie wählt --runner einen Job Service und ist ein anderer Vertrag. Der ausgemusterte alti-engine-job-Adapter gehört nicht zum Release-Inventar mit 24 Runnern; verstehen Sie akzeptierte local/private-Syntax nicht als ausgelieferten Dienst.

Wie eine lokale Engine gefunden wird

Bewahren Sie das installierte Release unverändert. XLS, Compute, gepacktes RTL, natives DDS und die typisierten PX-/CX-Pfade benötigen jeweils ihre benannte benachbarte ausführbare Datei. Die Vertrauensprüfung der Installation bindet geschützte Runner an Kataloghashes und Nachweise; kein PATH-Fallback oder vom Benutzer bereitgestellter Nachweis repariert diese Grenze. Ältere Kompatibilitätsresolver können sibling oder path melden; prüfen Sie den Nachweis für den tatsächlich ausgeführten Vorgang. Externe Werkzeuge wie Icarus besitzen eine eigene Host-Konfiguration.

Welche Engine welchen Namensraum bedient

Die Nutzlast enthält alti, alti-mcp, und diese 24 Engine-Runner:

alti-rtl-runner ist nicht enthalten. Kompatibilitätsbefehle für festgeschriebene Identität, die es anfordern, erhalten nicht allein durch vorhandene Hilfe Unterstützung. Die Desktop-Programmdatei, die ide open verwendet, wird separat verteilt.

Nachweis-Envelopes

Der stdout eines Engine-Envelopes ist eine Zeichenfolge mit dem nativen Ergebnis. Ohne --json lässt sich diese native Ausgabe direkt speichern und unverändert an einen passenden DDS-apply-Befehl übergeben. Reduzieren Sie einen Erstellungsplan niemals nur auf seinen Hash.

Umgebungsvariablen

Native Cloud verwendet --session-dir mit dem Standardwert ~/.local/state/altifigence/cloud-cli. Kopieren Sie keine Desktop-Sitzungsdateien dorthin, protokollieren Sie keine Tokens und senden Sie keine Service-Secrets an beliebige Endpoints.

Engine-Ergebnisse

Lesen Sie das tatsächliche Engine-Ergebnis und seine Grenzen. GPU-Erkennung ist keine GPU-Ausführung, ein Inhalts-Digest keine Signatur und eine Timing-Schätzung ohne Signoff keine Implementierungsfreigabe. Die nächste Seite listet die relevanten Engine-Befehle.

Einen Befehl vor dem Skripting klären

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

Prüfen Sie die Hilfe des exakten Endbefehls, den Sie aufrufen wollen. Ein passender Name in alti commands ersetzt weder die Hilfe des nativen Parsers noch installierte Fähigkeiten oder Laufzeitverfügbarkeit. Bewahren Sie die CLI-Version mit Skripten auf, da Anfrageschemas und Nachweise versioniert sind.