CLI-Befehlsreferenz

Überblick

Verwenden Sie das installierte Binary nach Verifikation und Installation. Diese Referenz unterscheidet Befehlserkennung, Ausführungsergebnisse, Vorprüfungsnachweise und Dienstantworten.

Aktionsmanifest

Bei Erfolg wird ein JSON-Array ausgegeben. Jeder Eintrag enthält name, description, inputSchema, executes, und class. Das eingebettete Kundenmanifest hat 25 Aktionen, davon 22 mit executes: true. altifigence.analyze.run, altifigence.evolve.launch, und altifigence.verify.run dienen nur der Planung. Native CLI-Unterbefehle besitzen über dieses Kundenmanifest hinaus eigene Hilfe für Endbefehle. Die Serverantwort bestimmt, ob ein Dienstvorgang autorisiert und bereit ist.

Verwenden Sie für native Argumente die Hilfe des Endbefehls:

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

Offline-Job-Vorprüfung

Bereiten Sie Quelle und Envelope unter Erster CLI-Erfolg vor und führen Sie dann aus:

Das Erfolgsschema ist altifigence.cli.engine-job-preflight.v1. submitted: false und server_authority_verified: false sind erforderlich: Quellhash und Job-Struktur wurden lokal geprüft, aber kein Job wurde eingereicht oder ausgeführt. Ein im Envelope angeforderter execution_placement ändert dies nicht.

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

JSON-Fehlervertrag

Ein fehlgeschlagener --json job validate schreibt keinen Erfolgsnachweis auf stdout und gibt ein altifigence.cli.error.v1-Objekt auf stderr aus:

Verwenden Sie error.code sofern verfügbar. Andere Befehlsfamilien besitzen eigene Fehlerschemas; nehmen Sie nicht an, dass dieses Envelope für jeden CLI-Befehl gilt.

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

Exit-Status

Prüfen Sie immer den Exit-Status vor dem Parsen von stdout und halten Sie stderr getrennt. Eine leere oder unvollständige Ausgabedatei ist kein erfolgreiches Ergebnis. Ein gespeicherter Plan ist keine angewendete Transaktion, und eine Serverannahme ist kein Job-Abschluss.

Engine-Befehle: Was tatsächlich läuft

Die XLS-, Compute- und nativen DDS-Adapter verwenden feste mitgelieferte benachbarte Dateien. Installierte Ausführung authentifiziert den jeweiligen Runner gegen seinen signierten Release-Eintrag; das Hinzufügen einer anderen ausführbaren Datei zu PATH kann eine fehlende erforderliche Nachbardatei nicht reparieren. Einige ältere Kompatibilitätsbefehle behalten ihr dokumentiertes Resolver-Verhalten. Siehe Befehlsoberfläche.

Ohne --json wird Engine-stdout weitergeleitet, sodass ein undurchsichtiger nativer Plan direkt gespeichert werden kann. Mit --json erzeugt ein Engine-Aufruf normalerweise altifigence.local-engine-execution.v1; dessen Felder stdout und stderr enthalten die Kindprozess-Datenströme als Zeichenfolgen. Parsen Sie das innere Ergebnis separat.

Übergeben Sie bei Datei- und Hierarchieplänen das gesamte native Planergebnis an den passenden apply-Befehl. Übergeben Sie weder das äußere CLI-Envelope noch nur einen Plan-Digest. Das native Backend validiert aktuelle Dateihashes und seine Transaktionsbedingungen.

Dienst- und Streaming-Ausgabe

ide service gibt altifigence.dds.service-receipt.v1 zurück mit operation, ok, httpStatus, und dem begrenzten Antwortinhalt body. HTTP 409 beim Ersetzen bleibt ein Konflikt und wird nicht wiederholt. Eine leere erfolgreiche DELETE-Antwort bleibt leer; es wird daraus kein Server-JSON-Objekt erfunden.

Native DDS-Suche und Cloud-Suche stellen ihre eigenen Treffer-/Inhaltsnachweise bereit. Verwenden Sie die Identität des Backends, in das Sie schreiben werden; ein für ein anderes Suchbackend berechneter Hash ist nicht automatisch ein gültiger CAS-Token.

ide cloud terminal streamt Terminalbytes auf stdout und Verbindungsstatus auf stderr. Es ist kein einzelner JSON-Nachweis, auch nicht mit globalem --json. Begrenzen Sie die Anbindungsdauer und bewahren Sie den Cursor auf, wenn Sie erneut verbinden möchten.

--json release install und --json release uninstall geben altifigence.cli.release-bootstrap.v1 aus mit operation, ok, und exitCode. Installerdiagnosen gehen auf stderr. Verifikations- oder Berechtigungsfehler können auftreten, bevor ein Erfolgs-Envelope besteht.

Ein Ergebnis für Automation erfassen

Wählen Sie für jeden Aufruf ein neues Ausgabeverzeichnis. Speichern Sie stdout und stderr getrennt, erfassen Sie den Exit-Status sofort und parsen Sie ein Erfolgsschema erst nach Exit null. Parsen Sie bei einem Engine-Envelope dessen stdout-Zeichenfolge nur dann als natives Dokument, wenn der Befehlsvertrag JSON-Inhalt angibt.

Bewahren Sie für einen Plan/apply-Workflow den vollständigen rohen nativen Plan auf und verwenden Sie dasselbe Projekt. Prüfen Sie betroffene Dateien und aktuelle Hashes vor apply. Ein Konflikt erfordert erneutes Lesen und einen geprüften Plan; er ist kein Grund, Hashprüfungen zu verwerfen. Siehe Automation und CI für eine reproduzierbare lokale Prüfung.