Aktions- und Funktionsvertrag
Aktionserkennung, Berichte installierter Funktionen, Vorprüfung, Ausführung und Serverzuständigkeit unterscheiden.
Überblick
Die CLI bietet ein Aktionsmanifest, Offline-Vorprüfung, Erkennung installierter Funktionen und explizite native Befehle. Der Bootstrap von 0.1.9 erstellt den signierten Installationsaufbau, den Funktionen benötigen. Diese Ausgaben beantworten unterschiedliche Fragen; keine sollte als Beweis für die anderen behandelt werden.
Kundenaktionsmanifest
Das versionierte Manifest enthält 25 Aktionen:
22 Aktionen sind als
executes=true;altifigence.analyze.run,altifigence.evolve.launchundaltifigence.verify.runsind die drei Aktionen zur reinen Planung.
executes=true bedeutet, dass die Aktion als ausführbar definiert ist. Der tatsächliche Befehl kann weiterhin eine lokale Engine, Kontoberechtigung oder einen Remote-Dienst benötigen. Eine Aktion zur reinen Planung validiert und liefert einen Plan, ohne einen Job auszuführen.
Verwenden Sie alti commands, um das mit dem aktuellen Programm ausgelieferte Manifest zu untersuchen. Kopieren Sie keine Befehlsliste aus einem anderen Release.
Beleg der Offline-Vorprüfung
Der Offline-job validate-Workflow verifiziert eine begrenzte CPU-RTL-Hülle und eine sichere workspacerelative Quelle. Ein erfolgreicher Beleg nennt ausdrücklich submitted: false und server_authority_verified: false. Er führt keine lokale Engine aus und kontaktiert keinen gehosteten Dienst. Siehe Erster Erfolg mit der CLI.
Funktionsvertrag der installierten Engine
Das Funktionsschema definiert folgende Zustände für ein korrekt installiertes Release mit Beleg:
Zustand | Bedeutung |
|---|---|
| Das installierte Release stellt die dokumentierte lokale Oberfläche bereit |
| Nur die gemeldete Teilmenge ist verfügbar |
| Das installierte Release kann die Oberfläche nicht bereitstellen |
| Die Oberfläche benötigt eine explizite dokumentierte Zustimmung |
| Die Aktion liefert einen Plan statt eines Ausführungsnachweises |
Folgen Sie Downloads verifizieren und Installation unter Linux, bevor Sie alti capabilities verwenden. Der eingebettete Bootstrap erstellt den authentifizierten Katalog-/Belegaufbau; kopieren Sie kein Programm an einen anderen Ort und fingieren Sie diesen Zustand nicht. Installierte Bereitschaft meldet verfügbare Funktionen. Der Nachweis, dass ein Design oder GPU-Job ausgeführt wurde, stammt aus seinem Ausführungsergebnis.
Frage | Beantwortet durch |
|---|---|
Wurde dieser Befehl hier ausgeführt, und mit welchem Ergebnis? | Den eigenen Exit-Status des Befehls und die Belegzeile mit Programm, Auflösung und Status |
Meldet dieses installierte Release die Funktion als verfügbar? | Einen erfolgreichen |
Ein erfolgreicher lokaler Befehl meldet, was auf diesem Rechner ausgeführt wurde. Automatisierung, die von einer installierten Produktfunktion abhängt, sollte außerdem den Funktionsbericht verlangen.
Quell-Uploads benötigen Zustimmung
Im standardmäßigen Kundenmodus verbirgt der mitgelieferte stdio-MCP-Server die drei Planaktionen, die Quelldateien enthalten können. Sie benötigen separate Umgebungszugangsdaten und verwenden den Cloud-Client. Das aktuelle öffentliche Release bietet für sie keinen vollständigen Remote-Ausführungsworkflow.
Der separate Modus ALTI_MCP_MODE=local-xls stellt feste lokale XLS-Werkzeuge ohne Cloud-Dispatch bereit. Native ide cloud-Operationen verwenden ihre eigene Anmeldung und expliziten Upload-Regeln; der Zustand der Kundenaktionen zur reinen Planung beschreibt nicht alle Cloud-Workspace-Operationen.
Eine Zustimmung erlaubt Übertragung; sie verwandelt eine reine Planaktion nicht in einen tatsächlichen Lauf und macht keinen Remote-Dienst verfügbar.
Jedes Ergebnis separat behandeln
Behandeln Sie bei der CLI-Automatisierung folgende Ergebnisse als unterschiedliche Zustände:
Eine lokale Funktion ist verfügbar;
eine Anfrage wurde validiert;
ein Plan wurde ohne Ausführung zurückgegeben;
Arbeit wurde von einer explizit freigeschalteten zuständigen Instanz akzeptiert;
Arbeit wurde abgeschlossen und erzeugte Nachweise;
eine Funktion oder zuständige Instanz war nicht verfügbar.
Werden diese Zustände zu einem einzigen Erfolgswert zusammengefasst, können ein Plan oder eine Vorschau wie abgeschlossene technische Arbeit aussehen.
Den richtigen Ergebnisvertrag wählen
Dokumentieren Sie für einen lokalen Lauf gewählte Engine, Eingabe-Digest, nativen Exit-Status und vollständiges Ergebnis. Bewahren Sie für Änderungen gespeicherter Dateien Plan und Anwendungsbeleg auf und lesen Sie die Datei erneut. Folgen Sie bei einem Remote-Job seiner ID bis zu einem endgültigen Zustand und rufen Sie dann das tatsächliche Ergebnis ab und verifizieren es. Ein Aktionsmanifesteintrag beschreibt nur die aufrufbare Schnittstelle.
Halten Sie lokale Engine-Anfragehüllen, Kundenplanaktionen und gespeicherte Cloud-RTL-Jobs in der Automatisierung getrennt. Sie unterscheiden sich in Eingabeschema, Quellort, Authentifizierung, Einreichung und Ergebnisbehandlung, selbst wenn ihre Namen „analyze“ oder „evolve“ enthalten.