Automatisierungsantworten

Versionierte Antworten

Bei --json erzeugt ein gewöhnlicher Befehlsaufruf ein Dokument mit schema_version 1 auf stdout. Hilfe/Version sind Click-Ausgabe und keine Befehlsantwort. Fragen und Diagnosen nutzen stderr; Fortschrittsanzeige entfällt. --json kann weiterhin fragen. Das vollständige unbeaufsichtigte Skript setzt zusätzlich --yes und ausdrückliche nichtdeterministische Auswahl.

Erfolg enthält schema_version (Ganzzahl), ok (true), command (Zeichenfolge) und result (Objekt). Fehler enthält schema_version, ok (false), command und error; error enthält code (maschinenlesbare Zeichenfolge), message (technischer Text) und details (Objekt). Unbekannte Codes benötigen übersetzte allgemeine Rückmeldung in öffentlichen Oberflächen. Automatisierung entscheidet anhand code/details und Ausgang, nicht Meldungswortlaut. Diese Antwort ist von SRT/VTT/ASS-Untertiteln unabhängig.

{
  "schema_version": 1,
  "ok": true,
  "command": "project.bindings",
  "result": {
    "bindings": []
  }
}

{
  "schema_version": 1,
  "ok": false,
  "command": "operation.start",
  "error": {
    "code": "input_required",
    "message": "",
    "details": {}
  }
}

Die leere message oben lässt technische Diagnoseworte bewusst weg; das Beispiel zeigt die Struktur. Erfolgreiche Befehle können mit Ausgang 0 und result.cancelled=true abgebrochen sein. Fehlerdetails hängen von Befehl und Zweig ab.

Feldinventar der Antworten

Felder sind im jeweiligen Erfolgs-/Fehlerzweig Pflicht. result und error.details sind befehlsspezifische offene Objekte; error.message ist technischer Diagnosetext. Schemaversion beider Beispiele wird gegen den Serializer geprüft.

Ausgangscodes

Prozessstatus für grobe Behandlung und stabilen Fehlercode für gezielte Wiederherstellung verwenden. Ungleich null bedeutet nicht, dass keine Operation gestartet oder Datei geschrieben wurde.

Stabile Fehlerzuordnung

Diese Maschinencodes gehören zu den obigen Prozess-Exits. Unbekannte Codes allgemein übersetzt behandeln; Details können angenommene Operations-IDs oder geschriebene Teilergebnisse behalten.

Befehlsergebnisfelder

Diese Inventare sind Vereinigungen tatsächlicher Ergebniszweige, keine Pflichtfeldliste jeder Antwort. Typen beschreiben dokumentierte serialisierte Werte; bei Any bleiben Wörterbücher offen. Export wählt die letzte erfolgreiche Stufe, sofern keine Artefaktauswahl dies ändert.

login

API-Token prüfen und für sein Gateway speichern. Verdeckte Eingabe oder geschützte Umgebung verwenden.

logout

Nur lokal gespeichertes Token entfernen. Umgebungsanmeldung bleibt aktiv; Serverwiderruf ist getrennt.

operation.apply

Bei Bedarf warten, erfolgreiche gespeicherte Artefakte wählen und lokale Ausgaben schreiben/registrieren. Fehlgeschlagene Eingaben fehlen; Teilexport braucht Zustimmung.

operation.start

Synchronisierte Medien prüfen, Quellen vorbereiten, schätzen, Kosten bestätigen, starten und liefern. Nach Annahme warten oder lösen; Export ist getrennt.

operation.supply

Zulässige awaiting_client-/awaiting_retry-Quellen derselben Operation liefern. Endgültiger Verarbeitungsfehler erfordert neue Operation.

Das folgende geprüfte Inventar nennt Felder in Objekt-/Arrayzweigen. Es ist ein Inventar, keine Antwort. Arrayelemente verwenden []. Abbruch kann das ganze Objekt weglassen. Typen und Bedeutung folgen den Feldbeschreibungen oben; Zähler nutzen die verschachtelten Ablaufschemata.

{
  "preparation_failures[]": [
    "content_id",
    "failure_code",
    "path"
  ]
}

operation.watch

Mit Echtzeithinweisen und HTTP-Abfragen Operationsstand verfolgen. Strg-C löst, ohne angenommene Arbeit abzubrechen.

Das folgende geprüfte Inventar nennt Felder in Objekt-/Arrayzweigen. Es ist ein Inventar, keine Antwort. Arrayelemente verwenden []. Abbruch kann das ganze Objekt weglassen. Typen und Bedeutung folgen den Feldbeschreibungen oben; Zähler nutzen die verschachtelten Ablaufschemata.

{
  "failures[]": [
    "content_id",
    "media_path",
    "reason"
  ]
}

project.bind

Lokale Datei oder Verzeichnis einem passenden gespeicherten Projekt zuordnen. Bindungen sind Cache, keine Inventarsynchronisierung.

Das folgende geprüfte Inventar nennt Felder in Objekt-/Arrayzweigen. Es ist ein Inventar, keine Antwort. Arrayelemente verwenden []. Abbruch kann das ganze Objekt weglassen. Typen und Bedeutung folgen den Feldbeschreibungen oben; Zähler nutzen die verschachtelten Ablaufschemata.

{
  "binding": [
    "api_url",
    "path",
    "path_kind",
    "project_id",
    "project_mode",
    "project_name",
    "user_id"
  ]
}

project.bindings

Bindungen ohne Backend-Prüfung oder Anmeldung lesen. Optionaler PATH filtert die lokale Liste.

Das folgende geprüfte Inventar nennt Felder in Objekt-/Arrayzweigen. Es ist ein Inventar, keine Antwort. Arrayelemente verwenden []. Abbruch kann das ganze Objekt weglassen. Typen und Bedeutung folgen den Feldbeschreibungen oben; Zähler nutzen die verschachtelten Ablaufschemata.

{
  "bindings[]": [
    "api_url",
    "bound_at",
    "path",
    "path_kind",
    "project_id",
    "project_mode",
    "project_name",
    "user_id",
    "validated_at"
  ]
}

project.forget

Lokale Bindungen nach Gateway/Konto entfernen; fehlende Pfade akzeptieren und keine Backend-Projekte löschen oder archivieren.

Das folgende geprüfte Inventar nennt Felder in Objekt-/Arrayzweigen. Es ist ein Inventar, keine Antwort. Arrayelemente verwenden []. Abbruch kann das ganze Objekt weglassen. Typen und Bedeutung folgen den Feldbeschreibungen oben; Zähler nutzen die verschachtelten Ablaufschemata.

{
  "removed[]": [
    "api_url",
    "project_id",
    "project_name",
    "user_id"
  ]
}

project.sync

Gesamte lokale Eingabe prüfen und Inventar abgleichen. Scan-/Analysefehler verhindern Teilübermittlung; veraltete Anwendung benötigt neue Vorschau.

Das folgende geprüfte Inventar nennt Felder in Objekt-/Arrayzweigen. Es ist ein Inventar, keine Antwort. Arrayelemente verwenden []. Abbruch kann das ganze Objekt weglassen. Typen und Bedeutung folgen den Feldbeschreibungen oben; Zähler nutzen die verschachtelten Ablaufschemata.

{
  "binding": [
    "api_url",
    "path",
    "path_kind",
    "project_id",
    "project_mode",
    "project_name",
    "user_id"
  ],
  "confirmed_moves[]": [
    "new_path",
    "old_path"
  ],
  "media": [
    "id",
    "path",
    "status"
  ],
  "media[]": [
    "id",
    "path",
    "status"
  ]
}

status

Wirksame Zugangsdaten und Gateway prüfen; Umgebungsüberschreibungen werden nicht gespeichert.

Vorbereitung und Teilausgabezweige

Unvollständiges start/supply liefert Ausgang 7, error.code=remote_rejection und error.details mit operation_id, preparation_incomplete=true und preparation_failures. Jeder Vorbereitungsfehler benennt path, content_id und failure_code; Beobachtungsfehler nutzen media_path, content_id und reason. ID behalten und zulässige Vorbereitungswiederherstellung verwenden.

Beobachtungsfehler nutzen Ausgang 8 und details.operation_id, status und failures. Teilexport kann erfolgreiche Dateien schreiben und dennoch Ausgang 8 liefern; details.result behält outputs, written_outputs, unchanged_outputs und selected_artifact_ids sowie Lebenszyklusfelder. Dieses Ergebnis vor Fehlermeldung erhalten. Fehlgeschlagene Quellelemente selbst sind nicht exportierbar. --yes --allow-partial bestätigt diesen Zweig ausdrücklich; --allow-partial allein erteilt keine unbeaufsichtigte Zustimmung.

Endgültig fehlgeschlagene Arbeit braucht eine neu und unabhängig geschätzte Operation. operation start nicht als allgemeine Antwort auf jeden Ausgang ungleich null wiederholen.